Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / standards / CCITT / 1992 / X / x435_2.asc < prev next >

Wrap

Text File | 1993-07-15 | 326.9 KB | 5,622 lines

6. Information Objects The information objects that users exchange in EDI messaging are of two kinds: EDI (abEDIM), and EDI notifications (abEDIN The glEDI messaging system user (abEDIMG user) is normally an glEDI application or computer process, not a person. For brevity, the term gluser is used throughout the rest of this Recommendation with the meaning of EDIMG user. tyInformationObject ::= CHOICE { edim [0] EDIM, edin [1] EDIN } 7. Common data types Information items of several kinds appears both in EDI messages and EDI notifications. These common items are defined below. 7.1 EDIM Identifier An g Identifier is an information item that unambiguously, globally and forever uniquely identifies an EDIM. It comprises an OR Name and a string which may for example contain a time or sequence number or other sufficient information to make this EDIM unique. tyEDIMIdentifier ::= SET { user [0] ORName, user-relative-identifier [1] LocalReference } NOTE - OR Name is defined in 8.5.5 of Recommendation X.411. The EDIM Identifier shares the same value set with the IPM Identifier defined in Recommendation X.420. Therefore an EDI user agent or EDI message store that is capable of handling both IPM and EDIM shall make sure that the Local Reference is unique both for IPMs and EDIMs. An EDIM Identifier has the following components: a) otUser: Identifies e user who originates the EDIM. One of the user's OR Names. b) otUser-relative-identifier: Unambiguously identifies the EDIM, distinguishing it from all other EDIMs that the user who is identified by the User component originates. A Printable String of from zero to a prescribed number of characters (see annex G). A length of zero is discouraged. (SI (SIZE (0..ub-local-reference)) .D. 7.2 Extensions A mechanism is provided which allows for future extensions to this Recommendation. .D.X435B.DOC,c004 c004 tyExtensionFieldty:ExtensionField ::= SEQUENCE { type [0] EDIM-EXTENSION, criticality [1] Criticality DEFAULT FALSE, value [2] ANY DEFINED BY type DEFAULT NULL NULL } .D. An Extension field can be marked critical (Criticality set to TRUE) or non-critical (Criticality set to FALSE) for acceptance of Responsibility. An extension marked as non-critical for Responsibility may be ignored or discarded, while an extension marked as critical must be known and performed for acceptance of Responsibility of an EDIM. NOTE - The term glEDIM Responsibilitygl:EDIM Responsibility is defined in 3.5 of Recommendation F.435. Throughout this document, the term "glResponsibilitygl:Responsibility" refers to the term defined in Recommendation F.435, and not to the everyday use of the word. .D.X435B.DOC,c005 c005 tyCriticalityty:Criticality ::= BOOLEAN .D. As a notation support for future definitions of extensions, a MACRO is defined. .D.X435B.DOC,c006 c006 maEDIM-EXTENSIONma:EDIM-EXTENSION MACRO ::= BEGIN TYPE NOTATION ::= DataType Critical | empty VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) DataType ::= type (X) Default | empty Default ::= "DEFAULT" value (X) | empty Critical ::= "CRITICAL" | empty END -- of extension .D. 8. EDI Messages An glEDI Messagegl:EDI Message (abEDIMab:EDIM) is a member of the primary class of information objects conveyed between users in EDI Messaging. NOTE 1 - The term glmessagegl:message when used throughout the rest of this Recommendation is a synonym for EDI Message. .D.X435B.DOC,c007 c007 tyEDIMty:EDIM ::= SEQUENCE { heading Heading, body Body } .D. An EDI Message consists of the following components: a) Heading: a set of Heading Fields (or Fields), each an information item that gives a characteristic of the EDI Message. b) Body: a sequence of one or more body parts tyBody ::= SEQUENCE { primary-body-part PrimaryBodyPart, additional-body-parts OtherBodyParts OPTIONAL } tyPrimaryBodyPart ::= CHOICE { edi-body-part [0] EDIBodyPart, forwarded-EDIM [1] EDIMBodyPart } tyOtherBodyParts ::= SEQUENCE OF EDIM- ExternallyDefinedBodyPart NOTE 2 - EDIM-Externally Defined Body Part is defined in . The Body has one Primary Body Part that contains an EDI information object. This body part is either an EDI interchange itself or a forwarded EDIM. Examples of types of EDI information objects are gl Interchanges defined by ISO 9735, Electronic data interchange for administration, commerce and transport (abEDIFACT), by United Nations Trade Data Interchange (abUNTDI ) and by American National Standards Institute committee X12 (abANSIX12). NOTE 3 - The scope of an EDI information object type is rather large and includes for example Privately Defined types. For brevity, the term glinterchange s used throughout the rest of this Recommendation with the meaning of EDI Interchange. The following rules comply with the requirements stated in 7.4 of Recommendation F.435: c) When an EDIM is first created, the Primary Body Part shall contain one EDI Body Part. d) When an EDIM is forwarded, its structure shall comply with the rules given in . The Primary Body Part has one of two basic forms: - the Primary Body Part contains an EDI information object - the Primary Body Part contains a forwarded EDI Message. Additionally, other body parts may be present in a message related to the Primary Body Part but of a different type. Examples of related body parts might be textual information, voice annotation or graphics to be used in conjunction with the interchange. The structure of an EDI Message is depicted in Figure . import F1.XGL /c 6.27";4.6";HPGLError! Cannot open file. FIGURE EDI Message Structure 8.1 Heading Field Component Types Information items of several kinds appear throughout the Heading. These common items are defined below. In the text that follows, reference is made to EDIFACT segments and data elements. Annex K to this Recommendation explains this in relation to UNTDI and ANSIX12. Values copied from EDI data elements and represented as T.61 Strings are semantically equivalent to the characters used to form the EDI data elements in EDIFACT, UNTDI and ANSIX12. 8.1.1 Interchange Recipient / Sender The Interchange Recipient and Interchange Sender fields have some data types in common. They are defined below. 8.1.1.1 Identification Code The Identification Code identifies a sender/recipient of an interchange. This is semantically identical to the "Sender identification/recipient identification code" component of the Interchange sender/recipient of the EDIFACT UNB segment. tyIdentificationCode ::= T61String (SIZE (1..ub-identification-code)) 8.1.1.2 Identification Code Qualifier The Identification Code Qualifier, if present, is a qualifier to the Identification Code of a sender/recipient. This is semantically identical to the "Identification code qualifier" component of the Interchange sender/recipient of the EDIFACT UNB segment. tyIdentificationCodeQualifier ::= T61String (SIZE (1..ub-identification-code- qualifier)) 8.1.1.3 Routing Address The Routing Address, if present, is an address for routing to the sender/recipient specified in the Identification Code. This is semantically identical to the "Address for reverse routing / Routing address" component of the Interchange sender/recipient of the EDIFACT UNB segment. tyRoutingAddress ::= T61String (SIZE (1..ub-routing-address)) 8.2 Heading Fields The fields that may appear in the Heading of an EDIM are defined and described below. tyHeading ::= SEQUENCE { this-EDIM [1] ThisEDIMField, originator [2] OriginatorField OPTIONAL, recipients [3] RecipientsField OPTIONAL, edin-receiver [4] EDINReceiverField OPTIONAL, responsibility-forwarded [5] ResponsibilityForwarded DEFAULT FALSE, edi-bodypart-type [6] EDIBodypartType DEFAULT {id- edifact-ISO646}, incomplete-copy [7] IncompleteCopyField DEFAULT FALSE, expiry-time [8] ExpiryTimeField OPTIONAL, related-messages [9] RelatedMessagesField OPTIONAL, obsoleted-EDIMs [10] ObsoletedEDIMsField OPTIONAL, edi-application-security-elements [11] EDIApplicationSecurityElementsField OPTIONAL cross-referencing-information [12] CrossReferencingInformationField OPTIONAL, -- Begin Fields from EDIFACT Interchange edi-message-type [13] EDIMessageTypeField OPTIONAL, service-string-advice [14] ServiceStringAdviceField OPTIONAL, syntax-identifier [15] SyntaxIdentifierField OPTIONAL, interchange-sender [16] InterchangeSenderField OPTIONAL, date-and-time-of-preparation [17] DateAndTimeOfPreparationField OPTIONAL, application-reference [18] ApplicationReferenceField OPTIONAL, -- End Fields from EDIFACT heading-extensions [19] HeadingExtensionsField OPTIONAL } NOTE - The names of the Heading fields derived from EDI standards are taken directly from the relevant standards. See also Annex K. 8.2.1 This EDIM The This EDIM field identifies the EDIM. It comprises an EDIM Identifier which provides a globally and forever unique identification for the EDIM. tyThisEDIMField ::= EDIMIdentifier NOTE - EDIM Identifier is defined in . 8.2.2 Originator Identifies the EDIM's originator. It comprises an OR Name. If the Originator field is not present in the EDIM Heading on reception, then the Originating-name of the delivery envelope shall be used to determine the originator of the EDIM (see 8.2.1.1.1.1 of Recommendation X.411). tyOriginatorField ::= ORName NOTE - OR Name is defined in 8.5.5 of Recommendation X.411. 8.2.3 Recipients The Recipients field identifies the user(s) and distribution lists(abDL) who e the (preferred) recipient(s) of the EDIM. It comprises a set of Recipients subfields, one for each recipient. If the Recipients field is not present in the EDIM Heading on reception, then the This-recipient-name of the delivery envelope shall be used to determine the recipient of the EDIM (see 8.3.1.1.1.3 of Recommendation X.411). NOTE - The fact that a message can be redirected or forwarded is reflected in the word "preferred" above. tyRecipientsField ::= SET OF RecipientsSubField The Recipients subfield is an information item that identifies a recipient of an EDIM and that may make certain requests of him. tyRecipientsSubField ::= SEQUENCE { recipient [1] RecipientField, action-request [2] ActionRequestField DEFAULT {id- for-action}, edi-notification-requests-field [3] EDINotificationRequestsField OPTIONAL, responsibility-passing-allowed [4] ResponsibilityPassingAllowedField DEFAULT FALSE, -- Begin Fields from EDIFACT UNB interchange-recipient [5] InterchangeRecipientField OPTIONAL, recipient-reference [6] RecipientReferenceField OPTIONAL, interchange-control-reference [7] InterchangeControlReferenceField OPTIONAL, processing-priority-code [8] ProcessingPriorityCodeField OPTIONAL, acknowledgement-request [9] AcknowledgementRequestField DEFAULT FALSE, communications-agreement-id [10] CommunicationsAgreementIdField OPTIONAL, test-indicator [11] TestIndicatorField DEFAULT FALSE, -- End Fields from EDIFACT UNB -- Begin Fields from ANSIX12 ISA authorization-information [12] AuthorizationInformationField OPTIONAL, -- End Fields from ANSIX12 ISA recipient-extensions [13] RecipientExtensionsField OPTIONAL } The Recipients subfield has the following components: 8.2.3.1 Recipient i in question. It comprises an OR Name. .D.X435B.DOC,c017 c017 tyRecipientFieldty:RecipientField ::= ORName .D. NOTE - OR Name is defined in 8.5.5 of Recommendation X.411. 8.2.3.2 Action Request An otAction Requestot:Action Request indicates what action the originator requests from the recipient. Its value is an object identifier. .D.X435B.DOC,c018 c018 tyActionRequestFieldty:ActionRequestField ::= OBJECT IDENTIFIER .D. The following standard values have object identifiers defined in this Recommendation: - For Action - Copy The absence of this field shall be interpreted as having the default value set to For Action. NOTE - Additional values for this field can be defined by any interested parties. 8.2.3.3 EDI Notification Requests The otEDI Notification Requestsot:EDI Notification Requests component (Default: no notifications, no notification security and no reception security) may make certain requests of the preferred recipient denoted by the Recipient field. NOTE - The fact that a message can be redirected or forwarded is reflected in the word "preferred" above. .D.X435B.DOC,c019 c019 tyEDINotificationRequestsFieldty:EDINotificationRequests Field ::= SEQUENCE { edi-notification-requests [0] EDINotificationRequests DEFAULT {}, edi-notification-security [1] EDINotificationSecurity DEFAULT {}, edi-reception-security [2] EDIReceptionSecurity DEFAULT {} } tyEDINotificationRequeststy:EDINotificationRequests ::= BIT STRING { pn (0), nn (1), fn (2) }(SIZE (0..ub-bit-options)) tyEDINotificationSecurityty:EDINotificationSecurity ::= BIT STRING { proof (0), non-repudiation (1) } (SIZE (0..ub-bit-options)) tyEDIReceptionSecurity ::= BIT STRING { proof (0), non-repudiation (1) }(SIZE (0..ub-bit-options)) The EDI Notification Requests field consists of a sequence of three bit strings of which the first selects the type of notification, the second selects what security function should be applied to that notification, and the third may make certain security requests for proof or non-repudiation of reception of this EDIM by the recipient. EDI Notification Security and EDI Reception Security shall not be requested if EDI Notifications are not requested. The EDI Notification Requests bit string may assume any of the following values simultaneously: a) PN: A notification of acceptance of Responsibility is requested in the circumstances prescribed in . b) NN: A notification of refusal of Responsibility of a message is requested in the circumstances prescribed in . c) FN: A forwarded notification is requested in the circumstances prescribed in . The absence of the EDI Notification Requests bit string implies that no EDI Notification requests are made. The EDI Notification Security bit string may assume any of the following values simultaneously: d) proof: When submitting the EDIN to the MTS, content-integrity-check shall be requested in the Message-submission-argument as defined in 8.2.1.1.1.28 in Recommendation X.411. e) non-repudiation: When submitting the EDIN to the MTS, content-integrity-check shall be requested in the Message-submission-argument as defined in 8.2.1.1.1.28 in Recommendation X.411 with a non-repudiable certificate. The absence of the EDI Notification Security bit string implies that no EDI Notification Security requests are made. The EDI Reception Security bit string may assume any of the following values simultaneously: message message-origin-authentication-check (depending on the security policy in force) in the Message-submission-argument as defined in 8.2.1.1.1.26, 28 and 29 of Recommendation X.411. g) non-repudiation: When submitting the ED N to the MTS, a non- repudiable content-integrity-check (possibly in the message token) or a message-origin-authentication-check (depending on the security policy in force) shall be requested. A notification shall contain the security elements and shall be signed on submission to the MT , using non-repudiable content-integrity- check (possib y in the message token) or message-origin- authentication-check (depending on the security policy in force) in the Message-submission-argument as defined in 8.2.1.1.1.26, 28 and 29 of Recommendation X.411 . The absence of the EDI Reception Security field implies that no EDI Reception Security requests are made. NOTE - Security services are available only if the MTA supports secure messaging. 8.2.3.4 Responsibility Passing Allowed The Responsibility Passing Allowed field indicates that forwarding Responsibility is allowed if this field is set to TRUE. Absence of the field shall be interpreted as the value FALSE. A recipient of a message with the Responsibility Passing Allowed field set to FALSE shall originate EDIN's as requested, and shall not forward Responsibility. .D.X435B.DOC,c029 c029 tyResponsibilityPassingAllowedFieldty:ResponsibilityPass ingAllowedField ::= BOOLEAN -- Default FALSE .D. If allowed, Responsibility may be forwarded to at most one recipient. 8.2.3.5 Interchange Recipient The otInterchange Recipientot:Interchange Recipient identifies the EDI Interchange recipient. This is semantically identical to the "Interchange recipient" of the EDIFACT UNB segment. .D.X435B.DOC,c021 c021 tyInterchangeRecipientFieldty:InterchangeRecipientField ::= SEQUENCE { recipient-identification-code [0] IdentificationCode, identification-code-qualifier [1] IdentificationCodeQualifier OPTIONAL, routing-address [2] RoutingAddress OPTIONAL } NOTE - The above fields are defined in . 8.2.3.6 Recipient Referenc otRecipient Reference identifies a reference meaningful to the recipient's EDI application. This is semantically identical to the "Recipient's Reference, Password" of the EDIFACT UNB segment. It consists of two strings. tyRecipientReferenceField ::= SEQUENCE { recipient-reference [0] RecipientReference, recipient-reference-qualifier [1] RecipientReferenceQualifier OPTIONAL } tyRecipientReference ::= T61String (SIZE (1..ub-recipient-reference)) tyRecipientReferenceQualifier ::= T61String (SIZE (1..ub-recipient-reference- qualifier)) 8.2.3.7 Interchange Control Reference Indicates the Interchange Control Reference as assigned by the Interchange sender. This is semantically identical to the "Interchange control reference" of the EDIFACT UNB segment. tyInterchangeControlReferenceField ::= T61String (SIZE (1..ub-interchange- control-reference)) 8.2.3.8 Processing Priority Code Indicates the EDI application Processing Priority Code. This is semantically identical to the "Processing priority code" in the EDIFACT UNB segment. It consists of a string. tyProcessingPriorityCodeField ::= T61String (SIZE (1..ub-processing-priority- code)) 8.2.3.9 Acknowledgement Request The Acknowledgement Request indicates the request for EDI acknowledgement as indicated by the interchange sender. This is semantically identical to the "Acknowledgement request" in the EDIFACT UNB segment. Its value is a Boolean, where the value TRUE indicates a request for acknowledgement. Absence of this field shall be interpreted as the value FALSE. tyAcknowledgementRequestField ::= BOOLEAN -- default FALSE 8.2.3.10 Communications Agreement Id The Communications Agreement Id indicates the type of Communications Agreement controlling the interchange, e.g. Customs or other agreement. This is semantically identical to the "Communications agreement id" in the EDIFACT UNB segment. tyCommunicationsAgreementIdField ::= T61String (SIZE (1..ub-communications- agreement-id)) 8.2.3.11 Test Indicator Indicates that the EDI Interchange is a test. This is semantically identical to the "Test indicator" in the EDIFACT UNB segment. It is a Boolean where the value TRUE indicates that the EDI Interchange is a test. Absence of this field shall be interpreted as the value FALSE. tyTestIndicatorField ::= BOOLEAN -- default FALSE 8.2.3.12 Authorization Information The Authorization Information indicates who authorized the interchange. This is semantically identical to the "Authorization information" in the ANSIX12 Interchange. tyAuthorizationInformationField ::= SEQUENCE { authorization-information [0] AuthorizationInformation, authorization-information-qualifier [1] AuthorizationInformationQualifier OPTIONAL } tyAuthorizationInformation ::= T61String (SIZE (1..ub-authorization-information)) tyAuthorizationInformationQualifier ::= T61String (SIZE (1..ub-authorization- information-qualifier)) NOTE - In the above text reference is made to ANSIX12 segments and data elements. Annex K to this Recommendation explains this in relation to UNTDI and EDIFACT (ISO 9735), being the other two widely used syntaxes. 8.2.3.13 Recipient Extensions The Rec otExtensions contains extensions to the Recipients subfield. tyRecipientExtensionsField ::= SET OF RecipientExtensionsSubField tyRecipientExtensionsSubField ::= ExtensionField There are no extensions defined in this Recommendation. 8.2.4 EDIN Receiver Identifies the recipient to whom EDINs are to be sent. This is created by the originator of the EDIM when the Recipient of a requested notification is different from the Originator of the message. It consists of a sequence of OR Name, EDIM Identifier and First Recipient. This field shall not be present if EDI Notification Requests are not made. This field shall be present in a forwarded message when the forwarding EDI user agent; (abED I message store; (abEDI-MS) forwards Responsibility. This field may be present when the forwarding EDI-UA accepts Responsibility. Rules related to the construction of this field are given in . NOTE 1 - For brevity, the t (abUA) is used throughout the rest of this Recommendation with the meaning of EDI-UA, and the term message store (abMS) is used throughout the rest of this Recommendation with the meaning of EDI-MS. tyEDINReceiverField ::= SEQUENCE { edin-receiver-name [0] ORName, original-edim-identifier [1] EDIMIdentifier OPTIONAL, first-recipient [2] FirstRecipientField OPTIONAL} The "first-recipient" field shall not be present if more than one recipient contains EDI Notification Requests. The "original-edim-identifier" and the "first-recipient" fields shall not be present when the Primary Body Part is an EDI Body Part (that is, when the original originator first creates the EDIM). NOTE 2 - The Original EDIM Identifier and First Recipient fields are included in order to allow the recipient to construct the EDIN for a forwarded EDIM. See (more specifically ) and for rules related to the construction of an EDIN; see for rules related to the First Recipient field when constructing a forwarded EDIM. OR Name is defined in 8.5.5 of Recommendation X.411. First Recipient Field is defined in . 8.2.5 Responsibility Forwarded The Responsibility Forwarded field is used to indicate whether Responsibility was forwarded. Absence of this field shall be interpreted as the value FALSE. tyResponsibilityForwarded ::= BOOLEAN -- Default False If this field has the value TRUE it indicates to a receiving UA that Responsibility was forwarded. If this field has the value FALSE (or is absent) it indicates to a receiving UA that the security elements of the inner envelope have been checked. hav have been checked when the message was forwarded. However, when Responsibility is accepted, the security elements shall be checked. NOTE - Rules regarding the use of this field are contained in and . 8.2.6 EDI Body Part Type Indicates the EDI standard and EDI character sets used in the Primary Body Part. It is represented by a single object identifier. NOTE 1 - This object identifier implements the element of service Character Set defined in Recommendation F.435. tyEDIBodyPartType ::= OBJECT IDENTIFIER -- default EDIFACT-ISO646 The following standard values have object identifiers defined in this Recommendation: - EDIFACT: ISO646|T61|UNDEFINED OCTETS - ANSIX12: ISO646|T61|EBCDIC|UNDEFINED OCTETS - UNTDI: IS0646|T61|UNDEFINED OCTETS - PRIVATE: UNDEFINED OCTETS - UNDEFINED: UNDEFINED OCTETS The absence of this field shall be interpreted as having the default value set to EDIFACT, ISO 646. NOTE 2 - The character set referred to by the object identifier is that in which both the EDI Body Part, and those Heading fields that are OCTET STRINGS and are derived from the EDI Interchange are encoded, notwithstanding the fact that these types are defined as OCTET STRING. The value of the EDI Body Part Type field shall be used in the Encoded Information Type ) in the MTS abstract operations (in accordance with ). This enables a UA to signal to the MTS what type of EDI standard the EDIM's Primary Body Part complies with. The MTS shall make use of this information, if the recipient UA has registered delivery restrictions on Encoded Information Types, to decide if it can deliver the EDI The term glEncoded Information Type is defined in 8.1 of Recommendation X.402. See also 8.2.1.1.1.23 of Recommendation X.411. 8.2.7 Incomplete Copy incomp incomplete copy of an EDIM. Its value is a Boolean. This field shall have the value TRUE if body parts are removed when an EDIM is forwarded. The absence of this field shall be interpreted as having the value FALSE. .D.X435B.DOC,c030 c030 tyIncompleteCopyFieldty:IncompleteCopyField ::= BOOLEAN -- Default False .D. NOTE - The term "subject EDIM" is defined in . 8.2.8Expiry Time Indicates when the originator considers this EDIM looses its validity. It comprises a date and time (UTC). .D.X435B.DOC,c032 c032 tyExpiryTimeFieldty:ExpiryTimeField ::= UTCTime .D. 8.2.9Related Messages Identifies messages that the originator of this EDIM considers related to it. It comprises a sequence of one or more message references, one for each related message. .D.X435B.DOC,c033 c033 tyRelatedMessagesFieldty:RelatedMessagesField ::= SEQUENCE OF RelatedMessageReference tyRelatedMessageReferencety:RelatedMessageReference ::= CHOICE { edi-message-reference [0] EDIMIdentifier, external-message-reference [1] ExternalMessageReference } tyExternalMessageReferencety:ExternalMessageReference ::= EXTERNAL .D. 8.2.10 Obsoleted EDIMs The Obsoleted EDIMs Field identifies one or more EDIMs that the present EDIM obsoletes. It is a sequence of subfields, each an EDIM Identifier. .D.X435B.DOC,c034 c034 tyObsoletedEDIMsFieldty:ObsoletedEDIMsField ::= SEQUENCE OF ObsoletedEDIMsSubfield tyObsoletedEDIMsSubfieldty:ObsoletedEDIMsSubfield ::= EDIMIdentifier .D. 8.2.11 EDI Application Security Elements The EDI Application Security Elements field allows an EDI application to exchange security elements having an end-to-end significance. EDIApplication EDIApplicationSecurityElement OPTIONAL, edi-encrypted-primary-bodypart [1] BOOLEAN OPTIONAL, edi-application-security-extensions [2] EDIApplicationSecurityExtensions OPTIONAL } tyEDIApplicationSecurityElementty:EDIApplicationSecurityElement ::= BIT STRING (SIZE (0..ub-edi-application-security- elements)) tyEDIApplicationSecurityExtensionsty:EDIApplicationSecurityExtensions ::= SEQUENCE OF EDIApplicationSecurityExtension tyEDIApplicationSecurityExtensionty:EDIApplicationSecurityExtension ::= ExtensionsField .D. 8.2.12 Cross Referencing Information The Cross Referencing Information allows an EDI application to reference individual body parts within the same EDIM and within other EDIMs. It contains a set of cross reference data. Its usage is outside the scope of this Recommendation. .D.X435B.DOC,c036 c036 tyCrossReferencingInformationFieldty:CrossReferencingInf ormationField ::= SET OF CrossReferencingInformationSubField tyCrossReferencingInformationSubFieldty:CrossReferencingIn formationSubField ::= SEQUENCE { application-cross-reference [0] ApplicationCrossReference, message-reference [1] MessageReference OPTIONAL, body-part-reference [2] BodyPartReference } tyApplicationCrossReferencety:ApplicationCrossReference ::= OCTET STRING tyMessageReferencety:MessageReference ::= EDIMIdentifier .D. NOTE - Body Part Reference is defined in . 8.2.13 EDI Message Type Indicates the Message type(s) present in the EDI Interchange. It consists of a set of strings. NOTE - "Message" is to be understood as message types that are defined in EDI standards and shall not be confused with "message" used elsewhere in this Recommendation. .D.X435B.DOC,c027 c027 tyEDIMessageTypeFieldty:EDIMessageTypeField ::= SET OF EDIMessageTypeFieldSubField tyEDIMessageTypeFieldSubFieldty:EDIMessageTypeFieldSubFiel d ::= T61String (SIZE (1..ub-edi-message-type)) .D. The values for this field shall be: - EDIFACT: Message Type from the UNH segment - ANSIX12: Transaction Set ID from the ST segment - UNTDI: Message Type from the MHD segment. 8.2.14 Service String Advice Indicates the Service String Advice of the EDI Interchange. This is semantically identical to the "UNA, Service string advice" of the EDIFACT Interchange. tyServiceStringAdviceField ::= SEQUENCE { component-data-element-separator [0] ComponentDataElementSeparator, data-element-separator [1] DataElementSeparator, decimal-notation [2] DecimalNotation, release-indicator [3] ReleaseIndicator OPTIONAL, reserved [4] Reserved OPTIONAL, segment-terminator [5] SegmentTerminator } tyComponentDataElementSeparator ::= OCTET STRING (SIZE (1)) tyDataElementSeparator ::= OCTET STRING (SIZE (1)) tyDecimalNotation ::= OCTET STRING (SIZE (1)) tyReleaseIndicator ::= OCTET STRING (SIZE (1)) tyReserved ::= OCTET STRING (SIZE (1)) tySegmentTerminator ::= OCTET STRING (SIZE (1)) 8.2.15 Syntax Identifier Indicates the syntax used. This is semantically identical to the "Syntax identifier" of the EDIFACT UNB segment. It consists of a sequence of the Syntax Identifier and the Syntax Version. tySyntaxIdentifierField ::= SEQUENCE { syntax-identifier SyntaxIdentifier, syntax-version SyntaxVersion } tySyntaxIdentifier ::= T61String (SIZE (1..ub-syntax-identifier)) tySyntaxVersion ::= PrintableString (SIZE (1..ub-syntax-version)) 8.2.16 Interchange Sender Indicates the sender of the EDI Interchange. This is semantically identical to the "Interchange sender" of the EDIFACT UNB segment. tyInterchangeSenderField ::= SEQUENCE { sender-identification [0] IdentificationCode, identification-code-qualifier [1] IdentificationCodeQualifier OPTIONAL, address-for-reverse-routing [2] RoutingAddress OPTIONAL } -- EDIFACT Routing Information NOTE - The above fields are defined in . 8.2.17 Date and Time of Preparation Indicates the Date/Time of preparation of the EDIM. This is in UTC Time and is derived from the "Date and time of preparation" of the EDIFACT UNB segment. It comprises a UTC time. tyDateAndTimeOfPreparationField ::= UTCTime 8.2.18 Application Reference Provides a general reference to an application or function. This is semantically identical to the "Application reference" segment of the EDIFACT UNB segment. It consists of a string. tyApplicationReferenceField ::= T61String (SIZE (1..ub-application-reference)) 8.2.19 Heading Extensions The Heading Extensions allows for future extensions to the Heading. tyHeadingExtensionsField ::= SET OF HeadingExtensionsSubField tyHeadingExtensionsSubField ::= ExtensionField There is no Extensions to the Heading defined in this Recommendation. NOTE - The Heading Extensions may be used to implement the element of service "Services Indication" defined in Recommendation F.435. 8.3Body Part Types The types of body parts that may appear in the Body of an EDIM are defined and described below. 8.3.1EDI Body Part An EDI Body Part carries a single EDI Interchange. tyEDIBodyPart ::= OCTET STRING The reference definition of EDI Interchange used is that used by EDIFACT (ISO 9735). Annex K to this Recommendation describes equivalent terms in other EDI standards. 8.3.2EDIM Body Part An EDIM Body Part contains an EDIM, and optionally, its delivery envelope. It is used for forwarding of EDIMs. When an EDIM is forwarded, its structure shall comply with the rules given in . tyEDIMBodyPart ::= SEQUENCE { parameters [0] MessageParameters OPTIONAL, data [1] MessageData } tyMessageParameters ::= SET { delivery-time [0] MessageDeliveryTime OPTIONAL, delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL, other-parameters [2] EDISupplementaryInformation OPTIONAL } tyMessageData ::= SEQUENCE { heading Heading, body BodyOrRemoved } tyBodyOrRemoved ::= SEQUENCE { primary-or-removed PrimaryOrRemoved, additional-body-parts AdditionalBodyParts OPTIONAL } tyPrimaryOrRemoved ::= CHOICE { removed-edi-body [0] NULL, primary-body-part [1] EXPLICIT PrimaryBodyPart } tyAdditionalBodyParts ::= SEQUENCE OF CHOICE { external-body-part [0] EDIM- ExternallyDefinedBodyPart, place-holder [1] BodyPartPlaceHolder } -- This type is for Body Part Removal tyBodyPartPlaceHolder ::= EDIM- ExternallyDefinedBodyPart -- Only the data -- portion of the Externally Defined Body shall be removed. -- See text in . tyEDISupplementaryInformation ::= IA5String (SIZE (1..ub-supplementary-info- length)) NOTE - Primary Body Part is defined in . Body Part Reference is defined in . Message Delivery Time and Other Message Delivery Fields are defined in 8.3.1.1 of Recommendation X.411. pre present) and data portions of the removed body part, only the Object Identifier and the tag of the "encoding" field of the EXTERNAL are preserved, that is, the EXTERNAL type shall have no content. The delivery envelope shall be present if security services are invoked. The structure of an EDIM Body Part is depicted in Figure . import F1A.XGL /c 6.27";4.6";HPGLError! Cannot open file. FIGURE EDIM Body Part StructureEDIM Body Part Structure 8.3.3Externally Defined Body Parts Additional body parts, that relate to the Primary Body Part, may be carried together with an EDI Body Part. These body parts shall not be or include EDI Interchanges. Additional body parts are externally defined and represent information objects whose semantics and abstract syntax are denoted by an object identifier which the body part carries. They have Parameters and Data components and optionally a Body Part Reference that may be used for cross-referencing to a body part. .D.X435B.DOC,c051 c051 tyEDIM-ExternallyDefinedBodyPartty:EDIM- ExternallyDefinedBodyPart ::= SEQUENCE { body-part-reference [0] BodyPartReference OPTIONAL, external-body-part [1] ExternallyDefinedBodyPart -- from IPMS --} tyBodyPartReferencety:BodyPartReference ::= INTEGER -- shall be unique within a EDIM .D. Body Part Reference is assigned when the body part is created, and is not modified subsequently. It shall be present if the originator wishes to cross-reference the body part at creation or in the future. NOTE - Some otExternally Definedot:Externally Defined body part types are defined in 7.3.12 of Recommendation X.420. 9.EDI Notifications An glEDI Notificationgl:EDI Notification (abEDINab:EDIN) is a member of a secondary class of information object conveyed between users in EDI Messaging. NOTE - The term glnotificationgl:notification is used throughout the rest of this Recommendation as a synonym for EDI Notification. .D.X435B.DOC,c052 c052 tyEDINty:EDIN ::= CHOICE { positive-notification [0] PositiveNotificationFields, negative-notification [1] NegativeNotificationFields, forwarded-notification [2] ForwardedNotificationFields } tyPN ::= EDIN -- with positive-notification chosen tyNN ::= EDIN -- with negative-notification chosen tyFN ::= EDIN -- with forwarded-notification chosen a) glpo e notification (abPN): An EDIN that reports its originator's acceptance of Responsibility of an EDIM. b) glnegative notification (abNN): An EDIN that reports its originator's refusal to accept Responsibility of an EDIM. c) glforwarded notification (abFN ): An EDIN that reports that Responsibility of an EDIM has been forwarded together with the subject EDIM. The EDIM to which an EDIN refers is called the glsubject EDIM (see also ). The recipient of the EDIN is the Originator of the subject EDIM, or, if present, the OR Name indicated in the EDIN Receiver field. There shall be at most one recipient specified for an EDIN. There shall be at most one PN, NN or FN originated for each subject EDIM by each recipient of whom notifications are requested (except that an NN may be originated by the same UA subsequent to an FN, in accordance with c) of ). One FN is originated, if and only if requested, by each recipient that forwards an EDIM. In accordance with the provisions of , the original originator shall receive at most one PN or NN for each recipient of whom notifications were requested, regardless of how many times the EDIM is forwarded, and may receive multiple FNs. An EDIN consists of Positive, Negative or Forwarded Notification fields. Each of these contains the Common fields which are described below. The structure of an EDIN is depicted in Figure . import F2.XGL /c 6.27";4.6";HPGLError! Cannot open file. FIGURE EDI Notification Structure 9.1Common Fields The Common fields are defined and described below. tyCommonFields ::= SEQUENCE { subject-edim [1] SubjectEDIMField, edin-originator [2] EDINOriginatorField, first-recipient [3] FirstRecipientField OPTIONAL, notification-time [4] NotificationTimeField, notification-security-elements [5] SecurityElementsField OPTIONAL, edin-initiator [6] EDINInitiatorField, notifications-extensions [7] NotificationExtensionsField OPTIONAL } NOTE - The Common fields appear in the Positive Notification, Negative Notification and Forwarded Notification fields defined below. 9.1.1Subject EDIM Identifier The Subject EDIM Identifier is the EDIM Identifier either passed in the EDIN Receiver field, if Responsibility has been forwarded, or the This EDIM field, if not. tySubjectEDIMField ::= EDIMIdentifier NOTE - EDIM Identifier is defined in . Subject EDIM is defined in . 9.1.2EDI Notification Originator The EDI Notification Originator contains the OR Name of the UA constructing the notification. tyEDINOriginatorField ::= ORName NOTE - OR Name is defined in 8.5.5 of Recommendation X.411. 9.1.3First Recipient The gl Recipient field contains the OR Name of the first recipient in a forwarding chain. This field, together with other fields, is used by the recipient of the notification to correlate the notification and the original message. tyFirstRecipientField ::= ORName NOTE - OR Name is defined in 8.5.5 of Recommendation X.411 If the originator of the EDIN is not the recipient specified by the original originator, then the First Recipient Field shall be present in the EDIN (see and more specifically ). 9.1.4Notification Time Notification Time contains the date and time, in UTC format, at which the notification for the subject EDIM was generated. tyNotificationTimeField ::= UTCTime 9.1.5Security Elements The Security Elements field is used to provide "proof/no repudiation of content received", "EDI application security" services. tySecurityElementsField ::= SEQUENCE { original-content [0] Content OPTIONAL, original-content-integrity-check [1] ContentIntegrityCheck OPTIONAL, edi-application-security-elements [2] EDIApplicationSecurityElementsField OPTIONAL, security-extensions [3] SecurityExtensionsField OPTIONAL } tySecurityExtensionsField ::= SET OF SecurityExtensionsSubField tySecurityExtensionsSubField ::= ExtensionField NOTE - The EDI Application Security Elements Field is defined in . Content and Content Integrity Check are defined in, respectively, 8.2.1.1.1.37 and 8.2.1.1.1.28 of Recommendation X.411. Security services are available only if the MTA supports secure messaging. specifies how these fields are filled in. 9.1.6EDIN Initiator The EDIN Initiator field can take one of the following values: a) "internal-UA" means that the UA generated the EDIN either for local reasons or because the generation had been delegated to it by the user. a) "internal-MS" means that the MS generated the EDIN either for local reasons or because the generation had been delegated to it by the user. c) "external-UA" means that the generation of the EDIN was requested by the user via the abstract operation Originate EDIN (see ). tyEDINInitiatorField ::= ENUMERATED { internal-ua (0), external-ua (1), internal-ms (2)} (0), eccannot-deliver-to-user (1), -- the EDI Interchange can not be passed on to the user ecdelivery-timeout (2), -- the EDI Interchange could not be passed on to the user within -- a specified time limit ecmessage-discarded (3), -- the UA/MS discarded the message before handoff to user ecsubscription-terminated (4), -- recipient's subscription terminated after delivery but before -- handoff to user ecforwarding-error (5), -- EDI Forwarding was attempted, but failed. ecsecurity-error (6) -- security error -- physical delivery errors indicated by "cannot- deliver-to-user" } (0..ub-reason-code) -- Negative Notification Diagnostic Codes from an EDI-UA or EDI-MS tyNNUAMSDiagnosticField ::= INTEGER { -- This field may be used to further specify the error signalled in nn-ua-ms-basic-code - Additional information may be indicated in nn- supplementary-information -- general diagnostic codes ecprotocol-violation (1), -- used if the UA detects a protocol error ecedim-originator-unknown (2), ecedim-recipient-unknown (3), ecedim-recipient-ambiguous (4), -- used if the EDIM recipients or originator are not valid ecaction-request-not-supported (5), -- used when the action requested by the recipient is not performed ecedim-expired (6), -- used when the expiry date of the received EDIM occurred before the subject EDIM -- was successfully passed to the user or forwarded by the EDI-UA ecedim-obsoleted (7), -- used when the EDIM Identifier of the received EDIM was contained in the Obsoleted EDIM field -- of a previously received EDIM. ecduplicate-edim (8), -- used when the same EDIM is received more than once from the same originator ecunsupported-extension (9), -- used if the EDIM contains an extension which is not supported by the UA ecincomplete-copy-rejected (10), -- used if the EDI-UA does not accept EDIMs with the Incomplete Copy Indication true ecedim-too-large-for-application (11), -- used if the EDIM cannot be delivered to the user due to length constraints -- forwarding error diagnostic codes ecforwarded-edim-not-delivered (12), -- used when an Non-Delivery Report is received for forwarded EDIM ecforwarded-edim-delivery-time-out (13), -- used when no Delivery Report is received within a given period ecforwarding-loop-detected (14), -- used if the UA receives an EDIM wich contains a previously forwarded EDIM ecunable-to-accept-responsibility (15), -- used if the EDI-UA cannot accept or forward responsibility -- interchange header diagnostic codes ecinterchange-sender-unknown (16), -- used when the UA does not recognizes the interchange-sender of the EDI interchange ecinterchange-recipient-unknown (17), -- used when the UA cannot find a valid interchange recipient in the Recipient Specifier ecinvalid-heading-field (18), ecinvalid-bodypart-type (19), ecinvalid-message-type (20), ecinvalid-syntax-id (21), -- security error diagnostic codes ecmessage-integrity-failure (22), ecforwarded-message-integrity-failure (23), ecunsupported-algorithm (24), ecdecryption-failed (25), ectoken-error (26), ecunable-to-sign-notification (27), ecunable-to-sign-message-receipt (28), ecauthentication-failure (29), ecsecurity-context-failure (30), -- Negative Notification Reason Codes from a user tyNNUserReasonCodeField ::= SEQUENCE { nn-user-basic-code [0] NNUserBasicCodeField, nn-user-diagnostic [1] NNUserDiagnosticField OPTIONAL } -- Negative Notification Basic Reason Codes from a user tyNNUserBasicCodeField ::= INTEGER { ecunspecified (0), ecsyntax-error (1), -- used when the user discovers a syntax error within the EDI interchange ecinterchange-sender-unknown (2), ecinterchange-recipient-unknown (3), -- used when the UA cannot find a valid interchange recipient in the Recipient Specifier ecinvalid-heading-field (4), ecinvalid-bodypart-type (5), ecinvalid-message-type (6), ecfunctional-group-not-supported (7), ecsubscription-terminated (8), -- unknown to EDIMS-User service ecno-bilateral-agreement (9), ecuser-defined-reason (10) } (0..ub-reason-code) -- Negative Notification Diagnostic Reason Codes from a user tyNNUserDiagnosticCodeField ::= INTEGER -- Contains reason passed by user when the value of nn- user-basic-code is user-defined-reason. -- Additional information may be indicated in nn- supplementary-information -- Negative Notification Reason Codes from a PDAU tyNNPDAUReasonCodeField ::= SEQUENCE { nn-pdau-basic-code [0] NNPDAUBasicCodeField, nn-pdau-diagnostic [1] NNPDAUDiagnosticField OPTIONAL } -- Negative Notification Basic Reason Codes from a PDAU tyNNPDAUBasicCodeField ::= INTEGER { ecunspecified (0), ecundeliverable-mail (1), -- used if the PDAU determines that it cannot perform physical delivery of the EDIM ecphysical-rendition-not-performed (2) -- used if the PDAU cannot perform the physical rendition of the EDIM } (0..ub-reason-code) -- Negative Notification Diagnostic Codes from a PDAU tyNNPDAUDiagnosticField ::= INTEGER { -- This field may be used to further specify the error signalled in nn-pdau-basic-code -- Additional information may be indicated in the nn- supplementary-information ecundeliverable-mail-physical-delivery-address- incorrect (1), ecundeliverable-mail-physical-delivery-office-incorrect- or-invalid (2), ecundeliverable-mail-physical-delivery-address- incomplete (3), ecundeliverable-mail-recipient-unknown (4), ecundeliverable-mail-recipient-deceased (5), ecundeliverable-mail-recipient-refused-to- accept (6), ecundeliverable-mail-organization- expired (7), ecundeliverable-mail-recipient-did-not- claim (8), ecundeliverable-mail-recipient-changed-address- permanently (9), ecundeliverable-mail-recipient-changed-address- temporarily (10), ecundeliverable-mail-recipient-changed-temporary- address (11), ecundeliverable-mail-new-address-unknown (12), ecundeliverable-mail-recipient-did-not-want forwarding (13), ecundeliverable-mail-originator-prohibited- forwarding (14), ecphysical-rendition-attributes-not-supported (15) } (1..ub-reason-code) 9.3.2NN Supplementary Information The NN Supplementary Information field may be used to return further information to the EDIN recipient to clarify the Negative Notification. NOTE - EDI Supplementary Information is defined in . 9.3.3Negative Notification Extensions The Negative Notification Extension s for future extensions to the NN. tyNNExtensionsField ::= SET OF NNExtensionsSubField tyNNExtensionsSubField ::= ExtensionField There are no extensions to the NN defined in this Recommendation. Extensions shall not be critical in NNs. 9.4Forwarded Notificat glForwarded Notification (abFN) is sent by a UA, if and only if the originator has requested one, when it determines that it cannot accept Responsibility and decides to forward the EDIM, and the EDI Notification Requests contained in the EDIM, to another UA. Forwarded Notification fields are defined and described below. tyForwardedNotificationFields ::= SEQUENCE { fn-common-fields [0] CommonFields, forwarded-to [1] ForwardedTo, fn-reason-code [2] FNReasonCodeField, fn-supplementary-information [3] EDISupplementaryInformation OPTIONAL, fn-extensions [4] FNExtensionsField OPTIONAL } 9.4.1Forwarded To The Forwarded To field indicates the new recipient of the (forwarded) subject EDIM. Its value is an OR Name. tyForwardedTo ::= ORName NOTE - OR Name is defined in 8.5.5 of Recommendation X.411. 9.4.2Forwarded Reason Code The Forwarded Reason Code indicates the reason why the Responsibility of the subject EDIM was forwarded. If any Basic Code field has the value "unspecified", additional information may be carried in any combination of a Diagnostic field or the FN Supplementary Info field. tyFNReasonCodeField ::= CHOICE { fn-ua-ms-reason-code [0] FNUAMSReasonCodeField, fn-user-reason-code [1] FNUserReasonCodeField, fn-pdau-reason-code [2] FNPDAUReasonCodeFields } -- Forwarding Notification Reason Codes from an EDI-UA or EDI-MS tyFNUAMSReasonCodeField ::= SEQUENCE { fn-ua-ms-basic-code [0] FNUAMSBasicCodeField, fn-ua-ms-diagnostic [1] FNUAMSDiagnosticField OPTIONAL, fn-security-check [2] FNUAMSSecurityCheckField DEFAULT FALSE } -- Forwarding Notification Basic Reason Codes from an EDI-UA or EDI-MS tyFNUAMSBasicCodeField ::= INTEGER { ecunspecified (0), econward-routing (1), -- used whenever the UA decides to re-route the subject EDIM for local reasons ecrecipient-unknown (2), ecoriginator-unknown (3), ecforwarded-by-edi-ms (4) } (0..ub-reason-code) -- Forwarding Notification Diagnostic Reason Codes from an EDI-UA or EDI-MS tyFNUAMSDiagnosticField ::= INTEGER { -- This field may be used to further specify the error signalled in fn-ua-ms-basic-code. -- Additional information may be indicated in fn- supplementary-information. ecrecipient-name-changed (0), ecrecipient-name-deleted (1) } (1..ub-reason-code) -- Forwarding Notification Security Check Codes from an EDI-UA or EDI-MS tyFNUAMSSecurityCheckField ::= BOOLEAN -- Forwarding Notification Reason Codes from a user tyFNUserReasonCodeField ::= SEQUENCE { fn-user-basic-code [0] FNUserBasicCodeField, fn-user-diagnostic [1] FNUserDiagnosticField OPTIONAL } -- Forwarding Notification Basic Reason Codes from a user ty FNUserBasicCodeField ::= INTEGER { ecunspecified (0), ecforwarded-for-archiving (1), ecforwarded-for-information (2), ecforwarded-for-additional-action (3), ecsubscription-changed (4), echeading-field-not-supported (5), ecbodypart-type-not-supported (6), ecmessage-type-not-supported (7), ecsyntax-identifier-not-supported (8), ecinterchange-sender-unknown (9), ecinterchange-sender-unknown (10), ecuser-defined-reason (11) } (0..ub-reason-code) -- Forwarding Notification Diagnostic Reason Codes from a user tyFNUserDiagnosticField ::= INTEGER -- Contains reason passed by user when value of fn-user- basic-code is user-defined-reason. -- Additional information may be indicated in fn- supplementary-information. -- Forwarding Notification Reason Codes from a PDAU tyFNPDAUReasonCodeField ::= SEQUENCE { fn-pdau-basic-code [0] FNPDAUBasicCodeField, fn-pdau-diagnostic [1] FNPDAUDiagnosticField OPTIONAL } -- Forwarding Notification Basic Reason Codes from a PDAU tyFNPDAUBasicCodeField ::= INTEGER { ecunspecified (0), ecforwarded-for-physical-rendition-and- delivery (1) } (0..ub-reason-code) -- Forwarding Notification Diagnostic Reason Codes from a PDAU tyFNPDAUDiagnosticField ::= INTEGER A physical delivery access unit (PDAU) (see ) is only able to generate NNs and FNs. If PN notification is requested, the PDAU shall generate an FN wi h appropriate Forwarded Reason Code ("forwarded-for- physical-rendition-and-delivery") when it has determined that it can render the EDIM for physical delivery. 9.4.3FN Supplementary Information The FN Supplementary Information field may be used to return further information to the EDIN recipient to clarify the Forwarded Notification. NOTE - The EDI Supplementary Information Field is defined in . 9.4.4Forwarded Notification Extensions The Forwarded Notifications Extensions allows for future extensions to the FN. tyFNExtensionsField ::= SET OF FNExtensionsSubField tyFNExtensionsSubField ::= ExtensionField There are no extensions to the FN defined in this Recommendation. Extensions shall not be critical in FNs. 10.Primary Object Types The environment in which EDI Messaging takes place can be modelled as an abstract object which is hereafter referred to as the Messaging Environment (abEDIME). vaedime OBJECT ::= id-ot-edime When refined (i.e., functionally decomposed), the EDIME can be seen to comprise lesser objects which interact by means of ports. vaedime-refinement REFINE edime AS edims origination [S] PAIRED WITH edimg-user reception [S] PAIRED WITH edimg-user edimg-user RECURRING ::= id-ref-primary The lesser objects are referred to as the glprimary object s of EDI Messaging. They include a single, central object, the EDI Messaging System, EDIMS, and numerous peripheral objects called EDI Messaging System users (users). The structure of the EDIME is depicted in Figure . import F3.XGL /c 6.27";4.6";HPGLError! Cannot open file. FIGURE The EDI Messaging Environment The primary object types are defined and described below. The types of ports by means of which they interact are discussed in . 10.1EDI Messaging User An glEDI Messaging user (abEDIMG user) is typically a computer process or glapplication that engages in EDI Messaging. Such processes or applications are referred to by the term "user" in this Recommendation. A user originates, receives, or both originates and receives Information Objects of the types defined in . vaedimg-user OBJECT PORTS { origination [C], reception [C] } ::= id-ot-edimg-user The EDIME comprises any number of Users. NOTE - EDI messaging is typically an activity between information processing systems. These are referred to as glEDI applications. This does not preclude the possibility of human interaction with the information processing systems which are performing EDI, or more direct interaction of a human user with the EDIMS. The terms "gluser" and "glEDIMG user" may be regarded as synonyms for EDI applications within this Recommendation. For brevity, the term "user" is used throughout the rest of this Recommendation with the meaning of "EDIMG user". 10.2EDI Messaging Syst glEDI Messaging System (abEDIMS) is the object by means of which all users communicate with one another in EDI Messaging. vaedims OBJECT PORTS { origination [S], reception [S] } ::= id-ot-edims The EDIME comprises exactly one EDIMS. 11.Primary Port Types The primary objects of EDI Messaging are joined to and interact with one another by means of ports. These ports, which the EDIMS supplies, are referred e glprimary ports of EDI Messaging. They are of the types defined below. NOTE - In to follow, the EDIMS is decomposed into still lesser objects, among which is the MTS. This fact is anticipated here by the inclusion of certain MTS capabilities in the EDIMS Abstract Service. 11.1Origination Port An glOriginatio t is the means by which a single user conveys to the EDIMS messages containing Information Objects of the types defined in . Through such a port the user originates EDI Messages and EDI Notifications. In addition, the user may originate probes through such a port. vaorigination PORT CONSUMER INVOKES { OriginateProbe, OriginateEDIM, OriginateEDIN } ::= id-pt-origination The EDIMS supplies one Origination Port to each user (with the exception of indirect users served by PDAUs (see ). 11.2Reception Port A glRecep Port is the means by which the EDIMS conveys to a single user messages containing Information Objects of the types defined in . Through such a port the user receives EDI Messages and EDI Notifications. In addition, the user may receive reports through such a port. vareception PORT SUPPLIER INVOKES { ReceiveReport, ReceiveEDIM, ReceiveEDIN } ::= id-pt-reception The EDIMS supplies one Reception Port to each user. 12.Abstract Operations What follows defines the abstract service that characterizes EDI messaging, and describes the environment in which that service is supplied and consumed. It does both using the abstract service definition conventions of Recommendation X.407. The g Abstract Service is the set of capabilities that the EDIMS provides to each user by means of one Origination Port and one Reception Port. Those capabilities are modelled as abstract operations, which may encounter abstract errors when invoked. The purpose of the EDIMS Abstract Service definition is not to prescribe the interface between the EDI user and the EDI-UA, but rather to clarify the meaning and intended use of the Information Objects of . A user interface need not provide commands in one-to-one correspondence to the service's abstract operations, nor indeed even divide the labour between the user and the EDIMS as the service does. The abstract operations available at the Origination Port and Reception Port are defined and described below. The abstract errors they may provoke are the subject of . The EDIMS Abstract Service involves neither abstract bind nor abstract unbind operations. The EDIMS authenticates (i.e., establishes the identity of) the typical user before offering the EDIMS Abstract Service to him. By this means it can verify, e.g., that the user is an EDIMS subscriber. Authentication, where required, is implicit (rather than explicit) in the definition of the EDIMS Abstract Service. NOTE - In to follow, the EDIMS is decomposed into objects among which is the MTS. The text here reflects this fact by its inclusion of various MTS-defined information items in the EDIMS Abstract Service. 12.1Origination Abstract Operations The abstract operations available at an origination port are invoked by the user and performed by the EDIMS. 12.1.1 Originate Prob otOriginate Probe abstract operation originates a probe concerning (a class of) messages whose contents are EDIMs. tyOriginateProbe ::= ABSTRACT-OPERATION ARGUMENT SET { envelope [0] ProbeSubmissionEnvelope, content [1] EDIM } RESULT SET { submission-identifier [0] ProbeSubmissionIdentifier, submission-time [1] ProbeSubmissionTime } ERRORS { RecipientImproperlySpecified } This abstract operation has the following arguments: a) otEnvelope: A e submission envelope, whose make-up the MTS Abstract Service defines. The UA supplies all but the following envelope components, which the user provides: 1) The desired per-message options (i.e., per-message indicators and extensions). 2) The OR Names of the preferred recipients and the per-recipient options (i.e., originator report request, explicit conversion, and extensions) desired for each. b) otContent n instance of the class of EDIM whose deliverability is to be probed. This abstract operation has the following resul otSubmission-identifier: The probe submission identifier the MTS assigns to the probe. d) otSubmission-time: The date and time the probe was directly submitted. 12.1.2 Originate EDI otOriginate EDIM abstract operation originates a message whose content is an EDIM. MessageSubmissionIdentif MessageSubmissionIdentifier, submission-time [1] MessageSubmissionTime } ERRORS { RecipientImproperlySpecified } .D. This abstract operation has the following arguments: a) otEnvelopeot:Envelope: A message submission envelope, whose make-up the MTS Abstract Service defines. The UA supplies all but the following envelope components, which the user provides: 1) The desired per-message options (i.e., priority, per-message indicators, deferred delivery time, and extensions). 2) The OR Names of the preferred recipients and the per-recipient options (i.e., originator report request, explicit conversion, and extensions) desired for each. b) otContentot:Content: The EDIM being originated. 1) If application to application security services are required, the user shall supply the value for the EDI Application Security Elements field. The EDIM shall be constructed as described in . This abstract operation has the following results: c) otSubmission-identifierot:Submission-identifier: The message submission identifier the MTS assigns to the submission. d) otSubmission-timeot:Submission-time: The date and time the message was directly submitted. 12.1.3 Originate EDIN The otOriginate EDINot:Originate EDIN abstract operation originates a message whose content is an EDIN. .D.X435B.DOC,g05 tyOriginateEDINty:OriginateEDIN ::= ABSTRACT-OPERATION ARGUMENT SET { envelope [0] MessageSubmissionEnvelope, content [1] EDIN } RESULT SET { submission-identifier [0] MessageSubmissionIdentifier, submission-time [1] MessageSubmissionTime } ERRORS { RecipientImproperlySpecified } .D. a abstract operation to indicate to the UA that it should accept, refuse or forward Responsibility for the subject EDIM. The exact type of EDIN to be generated (PN, NN or FN) is determined from the Content argument. An EDIN shall be originated only by an actual recipient of the subject EDIM of whom an EDIN is requested by means of the EDI Notification Request field of the subject EDIM's Recipient field. A user may delegate the task of generating EDINs to the UA. In this case, this abstract operation is not present at the abstract interface between the UA and the user, that is, the operation is not available at the Origination Port. In this case the UA behaves as described in . This abstract operation has the following arguments: a) otEnvelopeot:Envelope: A message submission envelope, whose make-up the MTS Abstract Service defines. The UA supplies all but the following envelope components, which the user provides: 1) The desired per-message options (i.e., priority, per-message indicators, and extensions). Implicit conversion shall be prohibited, priority shall be that of the subject EDIM. 2) The OR Names of the preferred recipients and the per-recipient options (i.e., explicit conversion and extensions) desired for each. The preferred recipient of the EDIN is the originator of the subject EDIM or, if present, the OR Name indicated in the EDIN Receiver field. b) otContentot:Content: The EDIN being originated. 1) If application to application security services are required, the user shall supply the value for the EDI Application Security Elements field. The EDIN shall be constructed as described in . This abstract operation has the following results: c) otSubmission-identifierot:Submission-identifier: The message submission identifier the MTS assigns to the submission. d) otSubmission-timeot:Submission-time: The date and time the message was directly submitted. 12.2Reception Abstract Operations The abstract operations available at a Reception Port are invoked by the EDIMS and performed by the user. mess messages because whether or not it does so for a particular user has no impact upon that user's ability to communicate with other users. Thus the provision of storage is a local matter. 12.2.1 Receive Report The otReceive Reportot:Receive Report abstract operation receives a report. .D.X435B.DOC,g06 tyReceiveReportty:ReceiveReport ::= ABSTRACT-OPERATION ARGUMENT SET { envelope [0] ReportDeliveryEnvelope, undelivered-object [1] InformationObject OPTIONAL } RESULT ERRORS {} .D. The report received may concern any of the following previously originated by the report's recipients: a) A message whose content was an EDIM that was originated with the Originate EDIM abstract operation or by forwarding. b) A message whose content was an EDIN that was originated as a result of a previously received message. The EDIN could be any of PN, NN or FN. c) A probe concerning a message whose content would have been an EDIM that was originated with the Originate Probe abstract operation. This abstract operation has the following arguments: d) otEnvelopeot:Envelope: A report delivery envelope, whose make-up the MTS Abstract Service defines. e) otUndelivered-objectot:Undelivered-object: The content of the message whose status is being reported. An EDIM or EDIN. If the report was provoked by a previous Originate Probe abstract operation invocation, this conditional argument shall be absent. If the report was provoked by a previous Originate EDIM abstract operation invocation, the argument shall be present if, and only if, content return was requested. This abstract operation has no results. 12.2.2 Receive EDIM The otReceive EDIMot:Receive EDIM abstract operation receives a message whose content is an EDIM. .D.X435B.DOC,g07 tyReceiveEDIMty:ReceiveEDIM ::= ABSTRACT-OPERATION ARGUMENT SET { envelope [0] MessageDeliveryEnvelope, content [1] EDIM } RESULT ERRORS {} This abstract operation has the following arguments: a) otEnvelope: The message's delivery envelope. b) otContent: The EDIM that is the message's content. This abstract operation has no results. When the received EDIM contains an EDIM Body Part (that is, when the original EDIM has been forwarded), it may be necessary to scan several levels of nested Heading fields in order to determine the correct original value for optional Heading fields (see for the nested structure of a forwarded EDIM and for rules related to Heading fields). 12.2.3 Receive EDIN The otRec EDIN abstract operation receives a message whose content is an EDIN. The EDIN is provoked by an EDIM originated with the Originate EDIM abstract operation. tyReceiveEDIN ::= ABSTRACT-OPERATION ARGUMENT SET { envelope [0] MessageDeliveryEnvelope, content [1] EDIN } RESULT ERRORS {} This abstract operation has the following arguments: a) otEnvelope: The message's delivery envelope. b) otContent: The EDIN that is the message's content. This abstract operation has no results. 13.Abstract Errors The abstract errors that may be reported in response to the invocation of the abstract operations available at the Origination Port and Reception Port are defined and described below or as part of the MTS Abstract Service definition. The set of abstract errors represented below is intended to be illustrative, rather than exhaustive. 13.1Recipient Improperly Specif otRecipient Improperly Specified abstract error reports that one or more of the OR Names supplied as arguments of the abstract operation whose performance is aborted, or as components of its arguments, are invalid. This abstract error is defined by the MTS Abstract Service. 14.Other capabilities In addition to the capabilities embodied in the EDIMS Abstract Service, defined above, the EDIMS shall transparently extend to each user the other MS (see Recommendation X.413) and MTS (see Recommendation X.411) capabilities identified below. (The enumeration of these capabilities necessarily anticipates the fact, stated in , that MSs and the MTS are among the EDIMS' component parts.) The following additional capabilities shall be provided: a) Submission: Capabilities of the MS' or MTS' submission port not embodied in the EDIMS Abstract Service, e.g., the ability to cancel delivery of a previously originated message whose content is an EDIM (but not an EDIN), if deferred delivery was selected. b) Delivery: Capabilities of the MTS' delivery port not embodied in the EDIMS Abstract Service, e.g., the ability to temporarily control the kinds of information objects the MTS conveys to the user's UA. c) Administration: The capabilities of the MS's or MTS's administration port. d) Retrieval: The capabilities of the MS' retrieval port. In addition to the above and as a local matter, the EDIMS may provide to users additional capabilities neither defined nor limited by this Recommendation. Among such capabilities are those of the Directory. NOTE - The required capabilities above are excluded from the formal definition of the EDIMS Abstract Service for purely pragmatic reasons, in particular, because their inclusion would largely and needlessly reproduce the definitions of the MS and MTS abstract operations upon which the capabilities are based. 15.Secondary Object Types The EDIMS can be modelled as comprising lesser objects which interact with one another by means of (additional) ports. vaedims-refinement REFINE edims AS mTS submission [S] PAIRED WITH edi-ua, edi-ms delivery [S] PAIRED WITH edi-ua, edi-ms administration [S] PAIRED WITH edi-ua, edi-ms edi-ua RECURRING origination [S] VISIBLE reception [S] VISIBLE edi-ms RECURRING submission [S] PAIRED WITH edi-ua retrieval [S] PAIRED WITH edi-ua administration [S] PAIRED WITH edi-ua pdau RECURRING reception [S] VISIBLE ::= id-ref-secondary These lesser objects are referred to as the glsecond objects of EDI Messaging. They include a single, central object, the MTS, and numerous peripheral objects: EDI messaging system us r agents (abEDI- UA ), EDI messaging system message stores (abEDI-MS), telematic agents (abTLMA), and physical delivery access units (abPDAU). Specification of the protocol for the TLMA may be the subject for future standardization. The structure of the EDIMS is depicted in Figure . As shown by the figure, EDI-UAs, EDI-MSs, and PDAUs are the instruments by means of which the EDIMS provides the EDIMS Abstract Service to users. import F4.XGL /c 6.27";4.6";HPGLError! Cannot open file. FIGURE The EDI Messaging System The secondary object types are defined and described below. The types of ports by means of which they interact are discussed in . The refinement above encompasses all possible interconnections of all possible objects. It ignores the possible absence of objects of a particular type (e.g., PDAU), and specific logical configurations of the MS. The latter are identified in Recommendation X.402. The MTS supplies import and export ports. However, since those ports are not formally defined (in Recommendation X.411), they are not included in the formal refinement above. Specification of a management port may be the subject for future standardization. 15.1EDI User Agent An g I user agent (abEDI-UA) is a UA tailored so as to better assist a single user to engage in EDI Messaging. It helps him originate, receive, or both originate and receive messages containing Information Objects of the types defined in . vaedi-ua OBJECT PORTS { origination [S], reception [S], submission [C], delivery [C], retrieval [C], administration [C] } ::= id-ot-edi-ua The EDIMS comprises any number of EDIMS UAs noted above, the term gluser agent (abUA) is used throughout this Recommendation with the meaning of EDI-UA. 15.2EDI Message Sto glEDI message store (abEDI-MS) is an MS tailored so as to better assist a single UA engaged in EDI Messaging. It helps it submit, take delivery of, or both submit and take delivery of messages containing Information Objects of the types defined in . vaedi-ms OBJECT PORTS { submission [S], retrieval [S], administration [S], submission [C], delivery [C], administration [C] } ::= id-ot-edi-ms The EDIMS comprises any number of EDIMS MSs. NOTE d above, the term glmessage store (abMS) is used throughout this Recommendation with the meaning of EDI-MS. 15.3Telematic Age gltelematic agent (abTLMA) is an AU that helps a single indirect user engage in EDI Messaging from a Telematic terminal, along with that terminal and the network that joins the two. A TLMA helps the user originate, receive, or both originate and receive messages containing Information Objects of the types defined in . Specification of the protocol for this AU may be the subject for future standardization. 15.4Physical Delivery Access Unit In the present context, a Physical Delivery Access Unit (abPDAU) helps any number f indirect users engage in EDI Messaging by means of a Physical Delivery System (abPDS). It helps them receive (but not originate) messages containing Information Objects of the types defined in . vapdau OBJECT PORTS { reception [S] } ::= id-ot-pdau The EDIMS comprises any number of PDAUs. A PDAU consumes import and export ports. However, since those ports are not formally defined (in Recommendation X.411), they are not included in the formal definition of PDAU above. If notifications are requested, the PDAU shall generate one of the following: - an FN with appropriate reason code if the PDAU determines that it can render and deliver the EDIM - a NN with appropriate reason code if the PDAU determines that it cannot render or deliver the EDIM. The use of the PDAU shall be subject to the requirements of the security policy in force. 15.5Message Transfer System In the present context, the glMessage Transfer System(abMTS) conveys Information Objects of the types defined in between UAs, MSs, and AUs. The EDIMS comprises a single MTS. The use of TLMA may be restricted by the security policy in force. 16.Secondary Port Types The secondary objects of EDI Messaging are joined to and interact with one another by means of ports. These ports, which MSs and the MTS supply, are refer glsecondary ports of EDI Messaging. They are of the types identified below. The capabilities embodied in one Submission, one Retrieval, and one Administration port constitute the MS Abstract Service. They are defined in Recommendation X.413. The capabilities embodied in one Submission, one Delivery, and one Administration Port constitute the MTS Abstract Service. They are defined in Recommendation X.411. NOTE - By means of the abstract bind operation which guards its ports, an MS or the MTS typically authenticates another secondary object before offering its abstract service to that object. Specification of a management port may be the subject for future standardization. 16.1Submission Port In the present context, a Submission Port is the means by which a UA (directly or indirectly) or an MS (directly) submits probes concerning, and messages containing Information Objects of the types defined in . An MS supplies one Submission Port to its UA. The MTS supplies one Submission Port to each UA configured without an MS and to each MS. 16.2Delivery Port In the present context, a Delivery Port is the means by which a UA or MS takes delivery of reports concerning and messages containing Information Objects of the types defined in . The MTS supplies one Delivery Port to each UA configured without an MS and to each MS. 16.3Retrieval Port In the present context, a Retrieval Port is the means by which a UA retrieves reports concerning and messages containing Information Objects of the types defined in . An MS supplies one Retrieval Port to its UA. 16.4Administration Port In the present context, an Administration Port is the means by which a UA changes information about itself or its user on file with its MS, or a UA or MS changes such information on file with the MTS. An MS supplies one Administration Port to its UA. The MTS supplies one Administration Port to each UA configured without an MS and to each MS. 16.5Import Port In the present context, an Import Port is the means by which the MTS imports reports concerning and messages containing Information Objects of the types defined in . The MTS supplies one Import Port to each AU. 16.6Export Port In the present context, an Export Port is the means by which the MTS exports probes concerning and messages containing Information Objects of the types defined in . The MTS supplies one Export Port to each AU. 17.User Agent Operation A UA must employ the MTS in a particular way in order to (correctly) provide the EDIMS Abstract Service to its user. If the user is equipped with an MS, the latter contributes to the provision of the abstract service and, therefore, is subject to the same rules. The rules that govern the operation of a UA (and MS) are the subject of what follows. The operation of a TLMA is beyond the scope of this Recommendation. NOTE - The purpose of what follows is not to dictate or constrain the implementation of a real UA unnecessarily, but rather to specify the effect to be achieved. 17.1Performance of Origination Operations A UA shall perform the abstract operations it makes available at its Origination Port as prescribed below. In the performance of these operations, the UA invokes the following abstract operations of the MTS Abstract Service (which, for what follows, are unqualified as to their source): a) Probe Submission b) Message Submission In response to the invocation of these abstract operations, a UA reports abstract errors as appropriate. Specification of the precise circumstances under which each abstract error should be reported is beyond the scope of this Recommendation. 17.1.1 Originate Probe A UA shall perform the Originate Probe abstract operation by invoking Probe Submission with the arguments indicated below, and by returning to its user the results indicated below. The arguments of Probe Submission shall be as follows: a) Envelope: The components of this argume t that constitute per- probe fields shall be as follows; those not explicitly mentioned below shall be as specified by Originate Probe's Envelope argument: 1) Originator-name: The OR Name of the UA's user. sp specified in - . 3) Content-identifier: Specified or omitted as a local matter. The components of this argument that constitute per-recipient fields shall be as specified by abstract operation Originate Probe's Envelope argument. The results of Originate Probe shall be as follows: b) Submission-identifie : Probe Submission's Probe-submission- identifier result. c) Submission-time: Probe Submission's Probe-submission-time result. The UA shall ignore all properties of Originate Probe's Content argument other than those mentioned above. How the UA employs Probe Submission's Content-identifier result is a local matter. 17.1.2 Originate EDIM A UA shall perform the Originate EDIM abstract operation by invoking Message Submission with the arguments indicated below, and by returning to its user the results indicated below. The arguments of Message Submission shall be as follows: a) Envelope: The components of this argume t that constitute per- message fields shall be as follows; those not explicitly mentioned below shall be as specified by Originate EDIM Abstract Operation Envelope argument: 1) Originator-name: The OR Name of the UA's user. 2) Content-type and Original-encoded-information-types: Determined from Originate EDIM's Content argument as specified in and , respectively. 3) Content-identifier: Specified or omitted as a local matter. 4) The security arguments on message submission are subject to the security policy in force. When the security policy specifies the support of Content Integrity Security Service, and when Notification Security is requested, the UA shall generate and submit the content-integrity-check Security Argument as defined in 8.2.1.1.1.28 in Recommendation X.411. The components of this argument that constitute per-recipient fields shall be as specified by abstract operation Originate EDIM's Envelope argument. To prevent an unknown number of EDINs from being sent to the original originator of a messa e in case of forwarding, "DL- expansion-prohibited", if available, may be set to TRUE if any of PN, NN or FN are requested. b) Content: Determined from Originate EDIM's Content argument (identified as an EDIM) as specified in . 1) If "proof/non-repudiation of Responsibility" notification is requested, the UA shall set the Notification Security field accordingly for each recipient as required. 2) If "proof/non-repudiation of content received" notification is requested, the UA shall set the Reception Security field accordingly for each recipient as required. 3) If "EDI application security" is requested, the end-to-end application security value shall be conveyed in the EDI Application Security Elements field. 4) If "proof/non-repudiation of content originated" is requested, the UA shall submit t e message using the "message-origin- authentication-check", or the "content-integrity-check" (possibly in the message token), according to the security policy in force. NOTE - In ca e of the use of a notarizing function, the non- repudiation of content service is provided implicitly, and is not reflected in any protocol elements. The results of Originate EDIM shall be as follows: c) Submission-identifier: Messa e Submission's Message-submission- identifier result. d) Submission-time: Message Submission's Message-submission-time result. How the UA employs Message Submission's Content-identifier result is a local matter. The inclusion of Message Submission's Extensions result among Originate EDIM's results is proper and may be the subject for future standardization. 17.1.3 Originate EDIN A UA shall perform the Originate EDIN abstract operation, if the UA makes it available to its user, by invoking Message Submission with the arguments indicated below, and by returning to its user the results indicated below. betwe between the UA and the user, that is, the operation is not available at the Origination port. In this case the UA behaves as if the abstract operation would have been invoked. The UA may accept Responsibility at will, but shall accept Responsibility when the EDIM is made available to the user, or when it forwards an EDIM with content changed (in this context, "content changed" means that the forwarding UA adds or removes body parts from the forwarding EDIM, in accordance with . The term forwarding EDIM is defined in ). A UA shall perform the Originate EDIN abstract operation by invoking Message Submission with the arguments indicated below, and by returning to its user the results indicated below. The arguments of Message Submission shall be as follows: a) Envelope: The components of this argume t that constitute per- message fields shall be as follows; those not explicitly mentioned below shall be as specified by the Originate EDIN abstract operation Envelope argument: 1) Originator-name: The OR Name of the UA's user. 2) Content-type and Original-encoded-information-types: Determined from the EDIN as specified in and , respectively. 3) Content-identifier: Specified or omitted as a local matter. 4) Deferred-delivery-time: Omitted. 5) Priority: Same as that of the subject EDIM. NOTE - Subject EDIM is defined in . b) Content: Determined from Originate EDIN's Content argument (identified as a PN, NN or FN) as specified in . 1) If, in the subject EDIM, Reception Security is s t to "non- repudiation" a d Notification Security is set to "non- repudiation" and the "content-integrity-check" security argument is present in the delivery envelope of the subject EDIM, then the "content-integrity-check" security argument is copied into the Content Integrity Check field of the EDIN. The UA shall submit the EDIN with a non-repudiable security element "content-integrity-check" (possibly in the message token) or a "message-origin-authentication-check" (depending on the security policy in force). 2) If, in the Subject EDIM, Reception Security is s t to "non- repudiation" a d Notification Security is set to "non- repudiation" and the "content-integrity-check" security argument is not present in the delivery envelope of the subject EDIM, then the Content of the subject message shall be copied into the Original Content field of the EDIN. The UA shall submit the EDIN with a non-repudiable security element "content-integrity-check" (possibly in the message token) or a "message-origin-authentication-check" (depending on the security policy in force). 3) If, in the Subject EDIM, Notification Security is set to "proof" the UA shall submit the EDIN with the security element "content-integrity-check" (possibly in the message token) or the "message-origin-authentication-check", according to the security policy in force. 4) If, in the Subject EDIM, EDI Notification Security is set to "non-repudiation" the UA shall submit t e EDIN with a non- repudiable security argument "content-integrity-check" (possibly n the message token) or a "message-origin- authentication-check", according to the security policy in force. 5) If the MTA does not support secure messaging, the EDIN shall contain an appropriate Reason Code. The results of Originate EDIN shall be as follows: c) Submission-identifier: Messa e Submission's Message-submission- identifier result. d) Submission-time: Message Submission's Message-submission-time result. How the UA employs Message Submission's Content-identifier result is a local matter. 17.2Invocation of Reception Operations A UA shall invoke the abstract operations available at its Reception Port as specified below. The UA invokes these operations in response to the MTS' invocation of the following abstract operations of the MTS Abstract Service (which, for what follows, are unqualified as to their source): a) Report Delivery b) Message Delivery The abstract operations of a Reception Port report no errors. 17.2.1 Receive Report Whenever the MTS invokes Report Delivery at a UA's Delivery Port, the UA shall invoke the Receive Report abstract operation with the following arguments: a) Envelope: Report Delivery's Envelope argument. b) Undelivered-object: Determined from Repo t Delivery's Returned- content argument as specified in . How the UA employs the Content-identifier component of Report Delivery's Envelope argument is a local matter. 17.2.2 Receive EDIM Whenever the MTS invokes Message Delivery at a UA's Delivery Port, and its Content argument encodes an EDIM as specified in , the UA shall invoke the Receive EDIM abstract operation with the following arguments: a) Envelope: Message Delivery's Envelope argument. b) Content: Determined from Message Delivery's Content argument as specified in (but no longer marked as an EDIM). 17.2.3 Receive EDIN Whenever the MTS invokes Message Delivery at a UA's Delivery Port, and its Content argument encodes an EDIN as specified in , the UA shall invoke the Receive EDIN abstract operation with the following arguments: a) Envelope: Message Delivery's Envelope argument. b) Content: Determined from Message Delivery's Content argument as specified in . 17.3Internal procedures A UA shall perform as specified below the internal procedures that relate to acceptance of Responsibility, refusal of Responsibility and forwarding. Security elements in any type of notification shall follow the rules of . A user may instruct its UA to accept or refuse Responsibility of incoming messages based on certain criteria. In addition, a user may instruct its UA to forward incoming messages based on certain criteria. Because of forwarding, it is possible for a UA to receive the same EDIM more than once. Mechanisms for detecting such duplicate receptions are not required, but may be a matter of local implementation by the UA. If they exist, and notifications are requested, the UA shall originate an NN. If they do not exist, and notifications are requested, the UA shall originate a PN or FN, as appropriate. The procedures involve the following abstract operations of the MTS Abstract Service (which, for what follows, are unqualified as to their source): a) Message Submission b) Message Delivery As implied by the above, in the course of the procedures, the UA has occasion to invoke Message Submission. What it does with the results of this abstract operation is a local matter. The UA shall consider as a candidate for each procedure individually every message for which all of the following conditions hold: c) The MTS has conveyed the message to the UA by invoking Message Delivery at the UA's Delivery Port. d) The UA has not conveyed the message to the user by invoking Receive EDIM at the UA's Reception Port. e) The message contains an EDIM (rather than an EDIN). With reference to item d) above, the message might be detained in the UA, e.g., as might be typical, because of the user's unavailability. 17.3.1 Acceptance of Responsibility A UA shall accept Responsibility when a message is successfully passed from the UA to the user. The UA shall follow the procedures below for each candidate message with respect to whose content the following condition holds: a) The EDIM requests a PN by means of the EDI Notification Request field of the subject EDIM's Recipients field. The UA may forward a message that it has accepted Responsibility for. See also on forwarding. 17.3.1.1 Construction of PN The UA shall construct a PN if, and only if, one is requested by means of the EDI Notification Requests field of the subject EDIM's Recipients field and in accordance with The PN shall have the following common fields: a) Subject EDIM: The Subject EDIM's ThisEDIM field or, if present, the Original EDIM Identifier in the EDIN Receiver field. b) EDIN Originator: The OR Name of the UA which submits the EDIN. of of the delivery envelope (see 8.3.1.1.1.4 of Recommendation X.411). d) Notification Time: The current date and time. 17.3.1.2 Submission of PN The UA shall submit the PN above by invoking Message Submission with the following arguments: a) Envelope: The components of this argument shall be as prescribed for performance of the Originate EDIN abstract operation with the following exceptions: 1) Priority: As specified by Message Delivery's Envelope argument. 2) Per-message-indicators: A local matter, except that conversion- prohibited shall be among the values specified. 3) Per-recipient-fields: A single field whose Recipient-name component shall be the Originator-name component of Message Delivery's Envelope argument, or if the EDIN Receiver field is present, the EDIN Receiver as specified by the originator of the message. NOTE - If the OR Name in the EDIN Receiver field is not valid, then the UA cannot submit the EDIN. Procedures to be followed in this case are a local matter. b) Content: Determined from the PN as specified in . 17.3.2 Refusal of Responsibility A UA shall refuse to accept Responsibility when a message cannot be successfully passed from the UA to the user. A UA may refuse to accept Responsibility when forwarding was unsuccesful (see c) of ). The UA shall follow the procedures below for each candidate message under the following conditions: a) The EDIM requests an NN of the UA's user by means of the EDI Notification Requests field of the subject EDIM's Recipients field. b) The EDIM is not forwarded. NOTE - See also on forwarding. 17.3.2.1 Construction of NN The UA shall construct an NN if, and only if, one is requested by means of the EDI Notification Requests field of the subject EDIM's Recipients field and in accordance with The NN shall have the common fields prescribed for Construction of PN (see ). The NN shall have the following fields: a) Negative Reason Code: The reason why Responsibility for the EDIM was refused. b) Optionally, supplementary information that adds information to the reason given. 17.3.2.2 Submission of NN The UA shall submit the NN (if any) above by invoking Message Submission. Its Envelope argument shall be as prescribed for Acceptance of Responsibility (see ), its Content argument determined from the NN as specified in . NOTE - If the OR Name in the EDIN Receiver field is not valid, then the UA cannot submit the EDIN. Procedures to be followed in this case are a local matter. 17.3.2.3 Handling of received EDIM The received EDIM for which the UA refuses Responsibility shall not be made available to the user. 17.3.3 EDI Forwarding The procedures defined in this paragraph describe glEDI Forwarding. NOTE - Fo the term "glforwarding" is used in this Recommendation as a synonym for "EDI Forwarding". A user may instruct its UA to forward received messages based on local criteria. A user may also instruct its UA to automatically forward requests for notifications together with the forwarded message. A message shall not be forwarded when Responsibility for that message has been refused. When Responsibility for a message has been refused, an NN shall be generated, if and only if one has been requested. In order to forward an EDIM, the UA creates a new EDIM with a new Heading and in the Primary Body Part encapsulates the received EDIM (Heading and Body) and optionally the envelope of the received message using the body part type EDIM Body Part (see ). Figure illustrates forwarding with an example. import F5.XGL /c 6.27";4.6";HPGLError! Cannot open file. FIGURE Forwarding The glsubject EDIM refers to the received EDIM that is being forwarded. The term glforwarding EDIM refers to the new EDIM that is being created, and that will include all or part of the subject EDIM, in accordance with . Unless overridden by specific rules below, or by the requirements of the security policy in force, the following general rules apply to the creation of the Heading fields of the forwarding EDIM: - All mandatory Heading fields and any optional fields whose values are changed with respect to the values present in the subject EDIM shall be present. - Heading fields whose values are unchanged and whose ASN.1 type is DEFAULT shall be copied from the subject EDIM Heading to the forwarding EDIM Heading if the field is present in the subject EDIM Heading and the value in the field is other that the value specified as DEFAULT in . - Other Heading fields need not be copied. EDI Forwarding is done by the MS if the UA has an MS, otherwise by the UA. EDI Forwarding may take two forms: a) Forwarding of message and Responsibility not accepted. b) Forwarding of message and Responsibility accepted. EDI Forwarding may take place even if no notifications have been requested. This is equivalent to form b) above. The UA shall, subject to the instructions given by the user, forward messages as follows. 17.3.3.1 Forwarding of message and Responsibility not accepted Forwarding a message without accepting Responsibility of the message implies the following: a) The Primary Body Part of the new message is the content of the subject message unchanged. The delivery envelope of the received EDIM shall be included if security notifications are requested. Responsibil Responsibility is allowed by the originator, the EDI Notification Request is forwarded unchanged with the new message to one, and only one, of the recipients of the new message. The value of the Responsibility Forwarded field shall be set to TRUE. c) If the forwarding fails (i.e a Non delivery report on the forwarded message is returned) within a given period of time (either specified by the originator in Expiry Time or as a local decision in the MS or UA, with priority given to the Expiry Time), the UA may send a Negative Notification, NN, back to the originator. d) If the EDI Notification Requests field of the subject EDIM's Recipients field requests FN, an FN EDIN shall be sent back to the specified EDIN Receiver, or to the originator of the EDIM, if no EDIN Receiver is specified. The delivery envelope of the received message shall be included in the new EDIM if the received EDIM's Primary Body Part is not a Forwarded EDIM. It is possible to forward a message more than once. A message may be forwarded to multiple recipients. The originator of a message may prohibit passing of Responsibility by setting the Responsibility Passing Allowed field to the value FALSE. In this case, if the UA cannot accept Responsibility and NN Notification is requested, the UA shall submit an NN EDIN with appropriate reason code. If the UA cannot accept Responsibility and NN Notification is not requested, then no EDIN shall be submitted. 17.3.3.2 Forwarding of message and Responsibility accepted Forwarding a message and accepting Responsibility of the message implies the following: a) The Primary Body Part of the new message is the content of the subject message changed or unchanged. This type of forwarding is less restricted and may include removal or addition of body parts. NOTE 1 - If the delivery envelope of the received message is included in the forwarded message, and if that envelope contained security fields, and if body parts are added or removed, then the security fields may no longer be valid. The following rules apply with respect to removal of body parts: 1) A forwarded EDIM Body Part shall not be removed. has has been removed (see ). 3) Body Part Place Holders shall be inserted where other body parts have been removed (see ). 4) the Incomplete Copy Indicator field shall be set to "TRUE" if Body Parts are removed. b) If the EDI Notification Requests field of the subject EDIM's Recipients field requests Positive Notification, a PN EDIN shall be sent back to the specified EDIN Receiver, or to the originator of the EDIM, if no EDIN Receiver is specified. c) A Forwarded Notification, FN, shall not be sent back to the originator of the message. d) The Responsibility Forwarded field shall not be present. NOTE 2 - By scanning the successive nested Headings of an EDIM that contains a forwarded EDIM, the final recipient UA can determine from the setting of the Responsibility Forwarded field at which point in the forwarding chain Responsibility was accepted. 17.3.3.3 Prevention of loops The UA shall suppress forwarding if, and only if, the EDIM to be forwarded itself contains a forwarding EDIM that the UA previously created. Forwarding shall be suppressed whenever the forwarding EDIM appears (directly) in a body part of the EDIM to be forwarded, or (nested) in a body part of the EDIM that appears in such a body part. The UA shall consider itself to have created the forwarding EDIM above if, and only if, the OR Name component of a This EDIM Field in a forwarded EDIM matches the OR Name of the UA's user. NOTE - Forwarding an EDIM of the kind described above would constitute an EDI Forwarding "loop". 17.3.3.4 Construction of EDIM The UA shall construct a forwarding EDIM whose Primary Body Part comprises a body part of type EDIM Body Part. Additionally, other body parts may be added, and body parts may be removed. The Heading shall have the following components: a) This EDIM: New value generated. b) Originator: OR Name of the forwarding user. c) Recipients: The recipients to which the EDIM shall be forwarded. d) Incomplete Copy: If present in the Heading of the subject EDIM. If Responsibility is not accepted, the following rules relating to the components of the EDIM Heading apply: e) EDIN Receiver Field: shall be present and shall contain all optional fields. If the subject EDIM contains an EDIN Receiver Field, the fields of the EDIN Receiver Field of the forwarding EDIM shall have the values of the fields of the EDIN Receiver Field of the subject EDIM. If optional fields are missing from the EDIN Receiver Field of the subject EDIM, or if the subject EDIM does not contain an EDIN Receiver Field, then the fields of the EDIN Receiver Field of the forwarding EDIM shall have the following values: 1) Edin-receiver: Originator of subject EDIM. 2) Original-edim-identifier: This EDIM field of subject EDIM. 3) First-recipient: OR Name of the UA to which the subject EDIM was first sent by the original originator. This is the OR Name of the forwarding UA (which is performing the first forwarding operation), unless the MTA has performed redirection. In case of redirection, the correct First Recipient OR Name must be obtained from the Intended Recipient Name field of the delivery envelope (see 8.3.1.1.1.4 of Recommendation X.411). f) EDI Notification Request (sub-field of Recipients): The UA may forward the EDIM to several recipients by simply adding recipients to the Recipients field. If EDI Notification Requests are present in the subject EDIM, the UA shall set identical EDI Notification Requests for one, and only one, of the recipients. One, and only one, of the UAs to whom the subject EDIM is forwarded will receive the EDI Notification Requests contained in the subject EDIM. g) Expiry Time: may be set to a value different to the value indicated in the subject EDIM. h) All other Heading fields shall follow the general rules in . If Responsibility is accepted, the EDIM Heading shall comply with a), b) and c) above and with the following rules: i) EDIN Receiver Field: may be absent or present. If present, it shall contain only the following value: 1) Edin-receiver: OR Name of the desired EDIN Receiver. j) Other fields may be added (including EDI Notification Requests). Other fields apart from those especially mentioned above may, but need not, be copied from the Heading of the subject EDIM to the Heading of the new EDIM (except that the Original EDIM Identifier and First Recipient sub-fields of the EDIN Receiver Field shall not be present). NOTE - If several recipients have the same OR Name, and notifications were requested from each, then the original originator may receive EDIN's which have identical Subject EDIM, EDIN Originator, and First Recipient fields. The Primary Body Part shall be of type EDIM Body Part and shall have the following components: k) Parameters: The Envelope argument of Message Delivery. l) Data: The EDIM to be forwarded. 17.3.3.5 Submission of EDIM The UA shall submit the EDIM it constructed above by invoking Message Submission with the following arguments: a) Envelope: The components of this argument shall be as follows: 1) Originator-name: The OR Name of the UA's user. 2) Content-type and Original-encoded-information-types: Determined from the EDIM as specified in and . 3) Content-identifier: Specified or omitted as a local matter. 4) Priority: As specified by Message Delivery's Envelope argument. 5) Per-message-indicators and Extensions: A local matter. 6) Deferred-delivery-time: Omitted. 7) Per-recipient-fields: Their Recipient-name components shall be the OR Names that the message shall be forwarded to. Their other components are a local matter. b) Content: Determined from the EDIM as specified in . 17.3.3.6 Construction of FN The UA shall construct an FN if, and only if, one is requested by means of the EDI Notification Requests field of the subject EDIM's Recipients field and the user is not willing to accept Responsibility for the message and forwards the request for notification. The FN shall have the common fields as prescribed for acceptance of Responsibility (See ). The FN shall have the following forwarding fields: a) Forwarded To: the OR Name of the recipient to whom the request for notification was forwarded. forw forwarded. c) Optionally, supplementary information that adds information to the reason given. 17.3.3.7 Submission of FN The UA shall submit the FN (if any) above by invoking Message Submission. Message Submission's Envelope argument shall be as prescribed for acceptance of Responsibility (See ), its Content argument determined from the FN as specified in . NOTE - If the OR Name in the EDIN Receiver field is not valid, then the UA cannot submit the EDIN. Procedures to be followed in this case are a local matter. 18.Message Store operation Recommendation X.413 defines the abstract service for a general content independent Message Store (MS). The MS is an optional system component in an MHS. The MS is asssociated with a user's UA. The user can submit messages through it and retrieve messages that have been delivered to the MS. In addition, the MS can perform certain predefined. auto actions on the UA's behalf. NOTE - Because the MS is an optional system component in an MHS, use of the word "shall" with respect to MS specifications shall not be construed as mandating the provision of an MS or the services it provides. Use of the word "shall" with respect to MS specifications shall be construed as mandating the specifications of an MS, if one is provided. All the abstract operations, general attribute types and general auto actions types defined in Recommendation X.413 are also available for use by EDI messages. An MS may optionally offer additional support for the EDI messaging specific attribute types and auto actions, which would qualify it as an EDI messaging specific MS (EDI MS). These additional definitions are given in what follows. 18.1Binding to the MS Binding to the MS is described in 7.1 of Recommendation X.413. Attention should be given to the following points when using the MS for EDI messaging. 18.1.1 Abstract-bind argument The following parameters from 7.1.1 of Recommendation X.413 have special meaning in this Recommendation: a) Fetch-restrictions The name of the object identifier for the EDI conte t type is "id- mct-pedi", the value is defined in Annex A. b) Allowed-EITs The names of the object identifiers so far standardized in this Recommendation are defined in Annex A. See also . 18.2Abstract-bind result The following parameter from 7.1.2 of Recommendation X.413 has special meaning for this Recommendation: - Available-auto-actions NOTE - The use of the general auto action "auto-forward" is discouraged for use with EDIMs. Instead the EDI messaging specific auto actions "edi-forward-with-responsibility-accepte " and "edi-forward-with- responsibility-not-accepted" should be used. 18.3Creation of Information Objects An MS shall satisfy the following requirements related to the information objects it maintains: a) The MS shall maintain a separate information object for each message containing an EDIM or EDIN that is delivered to it. b) The MS shall maintain as a separate information object not only each message containing a forwarding EDIM (pursuant to Item a) but also each message containing a forwarded EDIM (recursively). c) The MS shall assign sequence numbers to the messages in the hierarchy formed by a forwarding EDIM and its forwarded EDIMs. The lowest number shall be assigned to the outermost level of the hierarchy. The general (content independent) attributes that may occur in a stored-messages information-base are documented in Recommendation X.413. All content-independent MS attributes can be used for the content defined in this Recommendation. The EDI specific attributes for stored-messages are defined in . All general attribute types classified as "mandatory" in Table 1 of Recommendation X.413 shall be supported. 18.3.1 Mapping of an MHS message in MS NOTE - In what follows, reference is made to an "MHS message". This is not be confused with the term "message", which refers to an EDIM. Numbe Number, a Creation Time for the entry, the Interchange Length etc. It then generates attributes based on protocol elements in the MHS Envelope, in the Heading and one attribute containing the whole EDI Interchange. The attribute EDI Body Part Type signals which EDI Standard has been used. Similarly, other Body Parts will be mapped into one or several additional attributes. Figure describes how an MHS message with an EDIM is mapped into a corresponding MS entry. import F6.XGL /c 6.27";4.6";HPGLError! Cannot open file. FIGURE MHS Message with EDIM - Mapping in MS 18.3.2 Mapping of forwarded messages in MS A forwarded EDIM is mapped into the Message Store as one main entry and one or more linked child entries. The final child entry will contain the original EDIM (with its interchange and any additional body parts). The MS Structure of a forwarded message such as the message in Figure is depicted in Figure . import F7.XGL /c 6.27";4.6";HPGLError! Cannot open file. FIGURE Forwarded message in MS 18.4Maintenance of Attributes An MS shall satisfy the following requirements related to MS attributes: a) For each EDIM or EDIN it holds, the MS shall support the attributes of as specified therein. b) For each EDIM it holds, the MS shall give the following meanings to the defined values of the MS-status attribute: 1) new: No attribute values have been conveyed to the UA. 2) listed: At least one attribute value has been conveyed to the UA, and at least one body part value has not been conveyed to the UA. 3) processed: All body parts have been conveyed to the UA or the MS has performed an auto action. c) For each EDIN it holds, the MS shall give the following meanings to the defined values of the MS-status attribute: 1) new: No attribute values have been conveyed to the UA. 2) listed: At least one attribute value has been conveyed to the UA, and at least one attribute value has not been conveyed to the UA. 3) processed: All attributes have been conveyed to the UA or the MS has performed an auto action. d) The MS-status attribute shall reflect the state of affairs prior to an abstract operation invocation that alters its value. e) The Content Type attribute of each message containing an EDIM or EDIN that is delivered to the MS shall have as value the Object Identifier id-mct-edi (see Annex A). 18.5Negative Notification When it discards an EDIM while performing the Delete abstract operation of the MS Abstract Service, the MS shall submit an NN if one is requested and the EDIM's MS-status attribute has the value listed. 18.6Auto Action Types The concept of auto actions is described in 6.5 and 12 of Recommendation X.413. This defines two general auto action types, which can potentially be used for all content-types. However, the "auto-forward" auto action defined in there is not well suited for the EDIM content-type and its use for EDI messaging is discouraged. Instead, a specific auto action, for EDI Forwarding is defined below. The auto-alert auto action defined in 12.2 of Recommendation X.413 can be used for EDI messaging without any restrictions. Auto actions are registered and deregistered using the Register-MS abstract operation as described in 8.6 of Recommendation X.413. The EDI-auto-forward auto action is described in the following. The operation of this auto action may be affected by the implementation of a security policy. The auto action is described below together with its abstract syntax using the AUTO-ACTION macro is defined in 6.5 of Recommendation X.413. The definition of EDI-auto-forward auto actions are defined below. The EDI-auto-forward allows EDIMs to be forwarded as follows: - forwarding-with-responsibility-not-accepted, which means that the EDI responsibility is forwarded. See a) of ; - forwarding-with-responsibility-accepted, which means that the EDI responsibility is accepted. See b) of ; responsibili responsibility-accepted. If EDI Security Requests are present, then the EDI-auto-forward actions defined above may be prohibited, subject to the security policy in force. If EDI Security Requests are present then the EDI-auto-forward action "forwarding-with-responsibility-accepted" shall not be performed. The EDI-auto-forwa d allows one or more sets of EDI-forward- registration-parameters to be registered with the MS, each identified by its registration-identifier. Each EDI-forward-registration-parameter specifies criteria to determine whether it applies to a delivered EDIM, and if so, a copy of t e message is EDI-auto-forwarded using the Message- submission abstract operation. The delivered EDIM may be automatically deleted afterwards. Below is the ASN.1 definition of the edi-auto-forward AUTO ACTION: .D.X435B.DOC,a01 a01 moedi-auto-forwardmo:edi-auto-forward AUTO-ACTION REGISTRATION PARAMETER IS EDIForwardRegistrationParameter ::= id-act-edi-auto-forward moEDIForwardRegistrationParametermo:EDIForwardRegistration Parameter ::= SEQUENCE { filter [0] Filter OPTIONAL, edi-supplementary-info [1] EDISupplementaryInfo OPTIONAL, delete-after-forwarding [2] BOOLEAN DEFAULT FALSE, edi-forwarding-mode CHOICE { forwarding-with-responsibility-not-accepted [3] ForwardWithRespForwarded, forwarding-with-responsibility-accepted [4] ForwardWithRespAccepted } .D. NOTE - The data types Filter, Per Message Auto Forward Fields and Per Recipient Auto Forward Fields are defined in 12.1 of Recommendation X.413. The common parameters of the EDI Forward Registration Parameter have the following meanings: a) Filter: This is a set of criteria which a new entry representing a delivered EDIM shall satisfy for the MS abstract service provider to auto forward it using this set of parameters. The absence of this parameter indicates that all new entries are to be examined for potential auto forwarding. NOTE - Substrings in filters cannot be defined for composite attributes (attributes with further ASN.1 structure in the attribute value) in the present version of Recommendation X.413. b) Edi-supplementary-info: This parameter can contain text to be included in the EDIN supplementory field of an EDIN and in the other-parameters field of a forwarded EDIM. h has succeeded. If not specified, no deletion takes place. d) Edi-forwarding-type: This is a choice between: 1) forwarding-with-responsibility-not-accepted, 2) forwarding-with-responsibility-accepted, The remaining parameters are described separately for the three cases below. 18.6.1 Forwarding With Responsibility Not Accepted The forwarding-with-responsibility-not-accepted case enables the MS abstract service provider to automatically forward, with EDI Responsibility forwarded, any EDIM that has been delivered into the stored-messages information base. The use of this auto action shall be subject to the requirements of the security policy in force. The MS shall follow the rules in . Appropriate values are added in the EDI Notification Indication attribute. The following limitations apply to forwarding-with-responsibility-not accepted, when compared to the general rules for forwarding contained in : a) The forwarding-with-responsibility-not-accepted auto action type shall only be performed once for a particular EDIM by the same MS. b) Only one recipient shall be specified for the forwarding auto action. moForwardWithRespNotAccepted ::= SET { COMPONENTS OF PerMessageAutoForwardFields, -- from envelope PerMessageFields per-recipient-field [3] PerRecipientAutoForwardFields, notification-argument [4] NotificationArguments OPTIONAL } moNotificationArguments ::= SET { COMPONENTS OF PerMessageAutoForwardFields, -- from envelope PerMessageFields per-recipients-field [3] SEQUENCE SIZE (1..ub- recipients) OF PerRecipientAutoForwardFields } The following ASN.1 data type defines the parameters specific to this case: c) PerMessageAutoForwardFields: This is a set of arguments registered to be used for each message submission abstract operation (see 8.2.1.1.1 of Recommendation X.411). Any argument which is not registered, not mandatory, and not specifically mentioned below, will be absent from each message submission. If the following arguments are either not registered, or registered with their default values, the values used for each message submission abstract operation are those of the corresponding messa e delivery arguments: priority, implicit- conversion-prohibited, and conversion-with-loss-prohibited. If the following argument is either not registered, or registered with their default values, their presence as message submission arguments depends upon the presence of the corresponding message delivery arguments, their values being transformed where appropriate: message-security-label. The following arguments have fixed values: 1) DL-expansion-prohibited, value DL-expansion-prohibited 2) implicit-conversion-prohibite : value implicit-conversion- prohibited 3) conversion-with-loss-prohibited: val e conversion-with-loss- prohibited Certain message submission arguments may be registered. These are: proof-of-submission-reques , original-encoded-information- types and content-type. d) PerRecipientAutoForwardFields: This is a set of arguments registered to be used for each message submission abstract operation (see 8.2.1.1.1 of Recommendation X.411). Any argument which is not registered, not mandatory, and not specifically mentioned below, will be absent from each message submission. The following argument have a fixed value: 1) originator-report-request: this shall have either the value non-delivery-report or the value report. Only one recipient is allowed for this case. e) Notification-argument: This contains the same parameters as in c) and d) above, but the actual values can differ from the values in the forwarded EDIM. 18.6.2 Forwarding with responsibility accepted The forwarding-with-responsibility-accepted case enables the MS abstract service provider to automatically forward, with Responsibility accepted, any EDIM that has been delivered into the stored-messages information base. The use of this auto action shall be subject to the requirements of the security policy in force. The MS shall follow the rules in . Appropriate values are added in the EDI Notification Indication attribute. acce accepted, when compared to the general rules for forwarding contained in : a) The MS shall construct and forward an EDIM whose primary body part comprises a body part of type EDIM body part as described in , however no body parts shall be removed or added, the original delivery envelope shall be included and the components of the original Heading shall be copied to the Heading of the forwarding EDIM according to the rules in ; with the following exceptions: 1) The "recipient" parameter value is set to the next "recipient". 2) Any registered values for Heading fields shall replace the old values in the new Heading. .D.X435B.DOC,a03 a03 moForwardWithRespAcceptedmo:ForwardWithRespAccepted ::= SET { COMPONENTS OF PerMessageAutoForwardFields, -- from envelope PerMessageFields per-recipients-field [3] SEQUENCE SIZE (1..ub- recipients) OF PerRecipientAutoForwardFields, notification-argument [4] NotificationArguments OPTIONAL, heading-fields [5] HeadingFields OPTIONAL } moHeadingFieldsmo:HeadingFields ::= SEQUENCE { new-edin-receiver-name [0] ORName OPTIONAL, next-recipient [1] RecipientField, next-recipient-action-request [2] ActionRequestField DEFAULT {id-for-action}, next-recipient-edi-notification-requests-field [3] EDINotificationRequestsField OPTIONAL, next-responsibility-passing-allowed [4] ResponsibilityPassingAllowedField DEFAULT FALSE } .D. The following ASN.1 data type defines the parameters specific to this case: b) PerMessageAutoForwardFields: The description is the same as in c) of . c) PerRecipientAutoForwardFields The description is the same as in d) of . Multiple recipients are allowed for this case. d) Notification-argument: The description is the same as in e) of . e) HeadingFields: New values may be defined for: 1) "new-edin-receiver-name" to replace "edin-receiver-name" in EDIN Receiver Field. Field Field. This field is mandatory. 3) "next-recipient-action-request" to replace "recipient-action request" in Recipients Sub Field. 4) "next-recipient-edi-notification-requests-field" to replace "recipient-edi-notification-requests-field" in Recipients Sub Field. 5) "next-responsibility-passing-allowed" to "replace responsibility-passing-allowed" in Recipients Sub Field. 18.7Message Store Attributes As described in Recommendation X.413, an MS maintains and provides access to certain attributes of each information object it holds. An attribute comprises a type and, depending upon the type, one or more values. Attributes that may assume several values simultaneously (all pertaining to one object) are termed multi-valued, those that may assume just one value, single-valued. Some attributes pertain to information objects of all kinds, others only to those of e.g. EDI messaging kind. The following defines the MS attributes specific to EDI messaging. EDI specific attributes are defined below. All of the attributes defined in this Recommendation, except those corresponding to extended body part types (which cannot be enumerated), are listed alphabetically, for reference, in the first column of Table 1. This table records their presence in a delivered message entry. None of them appears in a delivered report entry. Additional, unnamed attributes are described in . Table 2 describes how the EDI attributes are generated. NOTE - See and for an elaboration of the legend of the tables. TABLE 1 Summary of EDI specific MS Attribute Types Attribute Single/ Support PresencePresencePresencePresenceAvailableAvail able Multi level by in in in infor list,for valued MS and delivereddelivereddelivered delivered alert summarize UA EDIM PN NN FN acknowledgement-request- S O P - - - Y N for-this-recipient action-request- S O P - - - Y N for-this-recipient application-reference S O C - - - Y N authorization-information- S O C - - - Y N for-this-recipient body S M P - - - N N communications-agreement-id- S O C - - - Y N for-this-recipient cross-referencing-information M O C - - - Y N date-and-time-of-preparation S M C - - - Y N edi-application-security-elements S O C - - - Y N edi-application-security-extentions M O C - - - Y N edi-body-part S M P - - - N N edi-bodypart-type S M P - - - Y Y edi-message-type M M C - - - Y N edi-notification-indicator M O - - - - Y N edi-notification-requests- S O C - - - Y N for-this-recipient edi-notification-security- S O C - - - Y N for-this-recipient edi-reception-security- S O C - - - Y N for-this-recipient edim-body-part S O C - - - N N edim-synopsis S O P - - - N N edims-entry-type S M P P P P Y Y edin-initiator S O - P P P Y N edin-originator S O - P P P Y N edin-receiver S O C - - - Y N expiry-time S O C - - - Y N externally-defined-body-part-types M O C - - - Y N first-recipient S O C C C C Y N fn-extensions M O - - - C Y N fn-reason-code S O - - - P Y N fn-supplementary-information S O - - - C Y N forwarded-to S O - - - P Y N heading S M P - - - N N heading-extensions M O C - - - Y N TABLE 1 (concluded) Attribute Single/ Support PresencePresencePresencePresenceAvailableAvail able Multi level by in in in infor list,for valued MS and delivereddelivereddelivered delivered alert summarize UA EDIM PN NN FN incomplete-copy S O P - - - Y N interchange-control-reference-S M C - - - Y N for-this-recipient interchange-lenght S O P - - - Y N interchange-recipient- S M C - - - Y N for-this-recipient interchange-sender S M C - - - Y N message-data S O C - - - N N message-parameters S O C - - - N N nn-extensions M O - - C - Y N nn-reason-code S O - - P - Y N nn-supplementary-information S O - - C - Y N notification-security-elementsS O - C C C Y N notification-time S O - P P P Y N notifications-extensions M O - C C C Y N obsoleted-edims M O C - - - Y N originator S O C - - - Y N pn-extensions M O - C - - Y N pn-supplementary-information S O - C - - Y N processing-priority-code- S O C - - - Y Y for-this-recipient recipient-extensions- M O C - - - Y N for-this-recipient recipient-reference- S O C - - - Y N for-this-recipient related-messages M O C - - - Y N responsibility-forwarded S O P - - - Y Y responsibility-passing-allowed- S O P - - - Y N for-this-recipient service-string-advice S O C - - - Y N subject-edim S M - P P P Y N syntax-identifier S M C - - - Y Y test-indicator- S O P - - - Y Y for-this-recipient this-edim S M P - - - Y N this-recipient S O P - - - Y N TABLE 2 Generation of the EDI specific MS Attribute Types Attribute-type-name Source Source Generation parameters generated rules by acknowledgement-request- acknowledgement- MDThe attribute-value is the value of the parameter for-this-recipient request in the recipient-sub-field for this recipient. If the source parameter is missing, an attribute with the default value shall be generated. action-request- action-request MDThe attribute-value is the value of the parameter for-this-recipient in the recipient-sub-field for this recipient. If the source parameter is missing, an attribute with the default value shall be generated. application-reference application-reference MD The value of the parameter is the attribute value. authorization-information- authorization- MDThe attribute-value is the value of the parameter for-this-recipient information in the recipient-sub-field for this recipient. body body MDThe value of the parameter is the attribute value. communications-agreement-id- communications- MD The attribute-value is the value of the parameter for-this-recipient agreement-id in the recipient-sub-field for this recipient. cross-referencing-information cross-referencing- MD A value is generated from each value information of the SET. date-and-time-of-preparation date-and-time-of- MD The value of the parameter is the attribute value. preparation edi-application-security-elements edi-application- MD The value of the parameter is the attribute value. security-elements edi-application-security-extentions edi-application- MD A value is generated from each value security-extentions of the SET. edi-body-part edi-body-part MDThe value of the parameter is the attribute value. edi-bodypart-type edi-bodypart-type MDThe value of the parameter is the attribute value. If the source parameter is missing, an attribute with the default value shall be generated. edi-message-type edi-message-type MDA value is generated from each value of the SET. edi-notification-indicator NONE MSA value is added when an EDIN is submitted from the MS. edi-notification-requests- edi-notification-requests MD The attribute-value is the value of the parameter for-this-recipient in the recipient-sub-field for this recipient. edi-notification-security- edi-notification-security MD The value of the parameter is the attribute value. for-this-recipient TABLE 2 (continued) Attribute-type-name Source Source Generation parameters generated rules by edi-reception-security- edi-reception-securityMD The value of the parameter is the attribute value. for-this-recipient edim-body-part NONE MSThe value is the sequence-number of the entry created for the forwarded EDIM. edim-synopsis se 18.7.1.2 MSse 18.7.1.2 edims-entry-type InformationObject MSIf the information object is an EDIM, the value is and edin set to "edim". If the information object is an EDIN, the value is set according to the type of the EDIN. edin-initiator edin-initiator MDThe value of the parameter is the attribute value. edin-originator edin-originator MDThe value of the parameter is the attribute value. edin-receiver edin-receiver MDThe value of the parameter is the attribute value. expiry-time expiry-time MDThe value of the parameter is the attribute value. externally-defined-body-part-types additional-body- MD From each component of the SEQUENCE, parts one value is generated from the value of the ExternallyDefinedData components direct- reference and one is generated from the value of the ExternallyDefinedParameters components direct-reference, if present. first-recipient first-recipient MDThe value of the parameter is the attribute value. fn-extensions fn-extensions MDA value is generated from each value of the SET. fn-reason-code fn-reason-code MDThe value of the parameter is the attribute value. fn-supplementary-information fn-supplementary- MD The value of the parameter is the attribute value. information forwarded-to forwarded-to MDThe value of the parameter is the attribute value. heading heading MDThe value of the parameter is the attribute value. heading-extensions heading-extensions MDA value is generated from each value of the SET. incomplete-copy incomplete-copy MDThe value of the parameter is the attribute value. If the source parameter is missing, an attribute with the default value shall be generated. interchange-control-reference- interchange- MD The attribute-value is the value of the parameter for-this-recipient control-reference in the recipient-sub-field for this recipient. TABLE 2 (continued) Attribute-type-name Source Source Generation parameters generated rules by interchange-lenght NONE MSThe value is the number of octets occupied by the source parameter. interchange-recipient- interchange-recipient MD The attribute-value is the value of the parameter for-this-recipient in the recipient-sub-field for this recipient. interchange-sender interchange-sender MDThe value of the parameter is the attribute value. message-data data MDThe value of the parameter is the attribute value. message-parameters parameters MDThe value of the parameter is the attribute value. nn-extensions nn-extensions MDA value is generated from each value of the SET. nn-reason-code nn-reason-code MDThe value of the parameter is the attribute value. nn-supplementary-information nn-supplementary- MD The value of the parameter is the attribute value. information notification-security-elements notification-security- MD The value of the parameter is the attribute value. elements notification-time notification-time MDThe value of the parameter is the attribute value. notifications-extensions notifications- MDA value is generated from each value extensions of the SET. obsoleted-edims obsoleted-EDIMs MDA value is generated from each value of the SEQUENCE. originator originator MDThe value of the parameter is the attribute value. pn-extensions pn-extensions MDA value is generated from each value of the SET. pn-supplementary-information pn-supplementary- MD A value of the parameter is the attribute value. information processing-priority-code- processing- MDThe attribute-value is the value of the parameter for-this-recipient priority-code in the recipient-sub-field for this recipient. recipient-extensions- recipient-extensions MD A value is generated from each value of the SET for-this-recipient in the recipient-sub-field for this recipient. recipient-reference- recipient-reference MD The attribute-value is the value of the parameter for-this-recipient in the recipient-sub-field for this recipient. related-messages related-messages MDA value is generated from each value of the SEQUENCE. TABLE 2 (concluded) Attribute-type-name Source Source Generation parameters generated rules by responsibility-forwarded responsibility-forwarded MD The value of the parameter is the attribute value. If the source parameter is missing, an attribute with the default value shall be generated. responsibility-passing-allowed- responsibility- MD The attribute-value is the value of the parameter for-this-recipient passing-allowed in the recipient-sub-field for this recipient. If the source parameter is missing, an attribute with the default value shall be generated. service-string-advice service-string-advice MD The value of the parameter is the attribute value. subject-edim subject-edim MDThe value of the parameter is the attribute value. syntax-identifier syntax-identifier MDThe value of the parameter is the attribute value. test-indicator-for-this-recipient test-indicator MD The attribute-value is the value of the parameter in the recipient-sub-field for this recipient. If the source parameter is missing, an attribute with the default value shall be generated. this-edim this-EDIM MDThe value of the parameter is the attribute value. this-recipient recipient MDThe attribute-value is the value of the parameter in the recipient-sub-field for this recipient. 18.7.1 Summary Attributes Some attributes summarize an EDI Messaging information object. These attributes are defined and described below. 18.7.1.1 EDIMS Entry Type The ot S Entry Type attribute identifies an information object's type. vaedims-entry-type ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDIMSEntryType MATCHES FOR EQUALITY SINGLE VALUE ::= id-sat-edims-entry-type tyEDIMSEntryType ::= ENUMERATED { edim (0), pn (1), nn (2), fn (3) } This attribute may assume any one of the following values: a) edim: The information object is an EDIM. b) pn: The information object is a PN. c) nn: The information object is an NN. d) fn: The information object is an FN. An MS that supports this attribute shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an EDIM or EDIN. 18.7.1.2 EDIM Synopsis otEDIM Synopsis attribute gives the structure, characteristics, size, and processing status of an EDIM at the granularity of individual body parts. This attribute is created when an EDIM is delivered to the MS. vaedim-synopsis ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDIMSynopsis SINGLE VALUE ::= id-sat-edim-synopsis The synopsis of an EDIM comprises a synopsis of each of its body parts. The synopsis appear in the order in which the body parts appear. tyEDIMSynopsis ::= SEQUENCE OF BodyPartSynopsis The synopsis of a body part takes either of two forms depending upon whether the body part is of type Message or Non-message (i.e. body-parts other than a forwarded EDIM). This enables the synopsis of a forwarding EDIM to encompass the body parts of each forwarded EDIM (recursively), as well as those of the forwarding EDIM itself. tyBodyPartSynopsis ::= CHOICE { message [0] MessageBodyPartSynopsis, non-message [1] NonMessageBodyPartSynopsis } tyMessageBodyPartSynopsis ::= SEQUENCE { number [0] SequenceNumber, synopsis [1] EDIMSynopsis } tyNonMessageBodyPartSynopsis ::= SEQUENCE { type [0] OBJECT IDENTIFIER, parameters [1] ExternallyDefinedParameters OPTIONAL, size [2] INTEGER, processed [3] BOOLEAN DEFAULT FALSE } The synopsis of a Message body part has the following components: a) otNumber: e sequence number that the MS assigns to the entry that the Message body part represents. This component is generated when a child- entry is created. form forms the content of the message that the body part represents. This component is generated when a child- entry is created. The synopsis of a body part of type other than Message has the following components. For purposes of this synopsis, the body part is considered to be of type Externally Defined, whether or not it was so conveyed to the MS: c) otTypeot:Type: This value is generated when the entry is created. If the Non-message Body Part is n edi-body- part, the value is the object identifier value contained in the edi-bodypart-type attribute contained in this entry. If it is a removed-edi-body, the value is set to "id-syn-removed" (See Annex C). If it is a place-holder, t e value is set to "id-syn-place- holder" (again, see Annex C). If t is an external- body-part, the value is set to the Direct-reference component of the body part's Data component. d) otParametersot:Parameters: This value is generated if the Non-message Body Part is an external-body-part. It contains that body part's Parameter component, which may describe the body part's format and control parameters. e) otSizeot:Size: This value is created when the entry is created. The value is set to the size in octets of the encoding of the Encoding component of the body part's Data component when the Basic Encoding Rules of Recommendation X.209 are followed. If those rules permit several (e.g., both primitive and constructed) encodings of the component, the size may reflect any one of them. f) otProcessedot:Processed (default false): An indication of whether or not the body part has been conveyed to the UA by means of the MS Fetch abstract operation, or has been processed by an auto action. This value is set to the default value when the EDIM is delivered to the MS and is updated as described in . An MS that supports this attribute shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an EDIM. As a consequence of its variability, the value of the Size component should be considered only an estimate of the body part's size. 18.7.2 EDI Notification Indicator s so which type of EDI Notifications were sent. The MS creates this attribute for each new EDIM and maintains the attribute values, depending on the auto actions performed. .D.X435B.DOC,e25 e25 vaedi-notification-indicatorva:edi-notification-indicator ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDINotificationIndicator DEFAULT (0) MATCHES FOR EQUALITY MULTI VALUE ::= id-sat-edi-notification-indicator EDINotificationIndicator ::= ENUMERATED { no-notification-sent (0), pn-sent (1), nn-sent (2), fn-sent (3) } .D. Each value of this attribute may assume one of the following values: a) no-notification-sent: This is the initial value set by the MS when a new MS entry is created for the EDIM. b) pn-sent: This value means that the MS has generated and sent a Positive Notification (PN) in response to a request for a PN. c) nn-sent: This value means that the MS has generated and sent a Negative Notification (NN) in response to a request for an NN. d) fn-sent: This value means that the MS has generated and sent a Forwarded Notification (FN) in response to a request for an FN. 18.7.3 Heading Attributes Some attributes are derived from the Heading of an EDIM. These attributes are defined and described below. 18.7.3.1 Heading The otHeadingot:Heading attribute is the (entire) Heading of an EDIM. .D.X435B.DOC,e05 e05 vaheadingva:heading ATTRIBUTE WITH ATTRIBUTE-SYNTAX Heading SINGLE VALUE ::= id-hat-heading .D. An MS that supports this attribute shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an EDIM. 18.7.3.2 Heading fields Some attributes bear the names of Heading fields and have those fields as their values. Some attributes bear the names of Heading fields and have sub-fields of those fields as their values. See for semantics. vathis-edim ATTRIBUTE WITH ATTRIBUTE-SYNTAX ThisEDIMField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-this-edim vaoriginator ATTRIBUTE WITH ATTRIBUTE-SYNTAX OriginatorField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-originator vaedin-receiver ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDINReceiverField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-edin-receiver varesponsibility-forwarded ATTRIBUTE WITH ATTRIBUTE-SYNTAX ResponsibilityForwarded MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-responsibility-forwarded vaedi-bodypart-type ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDIBodyPartType MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-edi-bodypart-type vaincomplete-copy ATTRIBUTE WITH ATTRIBUTE-SYNTAX IncompleteCopyField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-incomplete-copy expiry-time; ATTRIBUTE WITH ATTRIBUTE-SYNTAX ExpiryTimeField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-hat-expiry-time varelated-messages ATTRIBUTE WITH ATTRIBUTE-SYNTAX RelatedMessagesReference MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-related-messages vaobsoleted-edims ATTRIBUTE WITH ATTRIBUTE-SYNTAX ObsoletedEDIMsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-obsoleted-edims vaedi-application-security-element ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDIApplicationSecurityElement MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-edi-application-security-element vaedi-application-security-extensions ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDIApplicationSecurityExtension MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-edi-application-security-extensions vacross-referencing-information ATTRIBUTE WITH ATTRIBUTE-SYNTAX CrossReferencingInformationSubField MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-cross-referencing-information Fields from EDIFACT Interchange: vaedi-message-type ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDIMessageTypeFieldSubField MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-edi-message-type vaservice-string-advice ATTRIBUTE WITH ATTRIBUTE-SYNTAX ServiceStringAdviceField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-service-string-advice vasyntax-identifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX SyntaxIdentifierField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-syntax-identifier vainterchange-sender ATTRIBUTE WITH ATTRIBUTE-SYNTAX InterchangeSenderField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-interchange-sender vadate-and-time-of-preparation ATTRIBUTE WITH ATTRIBUTE-SYNTAX DateAndTimeOfPreparationField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-hat-date-and-time-of-preparation vaapplication-reference ATTRIBUTE WITH ATTRIBUTE-SYNTAX ApplicationReferenceField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-hat-application-reference Heading extensions: vaheading-extensions ATTRIBUTE WITH ATTRIBUTE-SYNTAX HeadingExtensionsSubField MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-heading-extensions ATTRIBUTE WITH ATTRIBUTE-SYNTAX InterchangeControlReferenceField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-rat-interchange-control-reference-for-this- recipient vaprocessing-priority-code-for-this-recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX ProcessingPriorityCodeField MATCHES FOR EQUALITY SINGLE VALUE ::= id-rat-processing-priority-code-for-this-recipient vaacknowledgement-request-for-this- recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX AcknowledgementRequestField MATCHES FOR EQUALITY SINGLE VALUE ::= id-rat-acknowledgement-request-for-this-recipient vacommunications-agreement-id-for-this- recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX CommunicationsAgreementIdField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-rat-communications-agreement-id-for-this- recipient vatest-indicator-for-this-recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX TestIndicatorField MATCHES FOR EQUALITY SINGLE VALUE ::= id-rat-test-indication-for-this-recipient -- END Fields from EDIFACT -- Fields from ANSIX12 ISA vaauthorization-information-for-this- recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX AuthorizationInformationField MATCHES FOR EQUALITY SINGLE VALUE ::= id-rat-authorization-information-for-this-recipient -- END Fields from ANSIX12 ISA Extensions: varecipient-extensions-for-this-recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX RecipientExtensionsSubField MATCHES FOR EQUALITY MULTI VALUE ::= id-rat-recipient-extensions-for-this-recipient An MS that supports one of these attributes shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an EDIM whose Heading Recipients field contains the field whose name the attribute bears. It shall maintain one attribute value for each sub-field. 18.7.4 Body Attributes Some attributes are derived from the Body of an EDIM. These attributes are defined and described below. 18.7.4.1 Body The otBody attribute is the (entire) Body of an EDIM. vabody ATTRIBUTE WITH ATTRIBUTE-SYNTAX Body SINGLE VALUE ::= id-bat-body An MS that supports this attribute shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an EDIM. 18.7.4.2 Body Analyses Some attributes have as their values information about the body parts contained in the body of the message. The interchange length attribute is created by the Message Store when it receives an EDIM. Its value indicate the length of the EDI Interchange carried in the Primary Body Part of the message. vainterchange-length ATTRIBUTE WITH ATTRIBUTE-SYNTAX InterchangeLength MATCHES FOR ORDERING SINGLE VALUE ::= id-bat-interchange-length tyInterchangeLength ::= INTEGER The Interchange Length gives the number of octets occupied by the EDI Interchange. 18.7.4.3 Primary Body Parts Some attributes bear the names of the Primary Body Part types and have such body parts as their values. See for semantics. vaedi-body-part ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDIBodyPart SINGLE VALUE ::= id-bat-edi-body-part tyEDIExternallyDefinedBodyPartParameterAttribute ::= SEQUENCE { body-part-reference [0] BodyPartReference OPTIONAL, parameter [1] ExternallyDefinedParameters } An MS that supports one of these body parts shall maintain both attributes for an information object that it holds if, and only if, that object is a message whose content is an EDIM whose Body contains one or more body parts of the type that corresponds to that attribute. It shall maintain one value of each attribute for each such body part. NOTE - The externally defined body part attributes cannot be enumerated in practice because the externally defined body part types cannot be so enumerated. The Externally Defined Body Part Types attribute determines the Externally Defined Body Part Types for a particular EDIM. 18.7.5 Notification Attributes Some attributes are derived from an EDIN. These attributes are defined and described below. 18.7.5.1 Common fields Some attributes bear the names of Common fields and have those fields as their values. See 6.1 for semantics. vasubject-edim ATTRIBUTE WITH ATTRIBUTE-SYNTAX SubjectEDIMField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-subject-edim vaedin-originator ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDINOriginatorField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-edin-originator vafirst-recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX FirstRecipientField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-first-recipient vanotification-time ATTRIBUTE WITH ATTRIBUTE-SYNTAX NotificationTimeField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-nat-notification-time vanotification-security-elements ATTRIBUTE WITH ATTRIBUTE-SYNTAX SecurityElementsField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-notification-security-elements vaedin-initiator ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDINInitiatorField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-edin-initiator Some attributes be r the names of notification fields and have sub- fields of the Common fields of a notification as their values. vanotification-extensions ATTRIBUTE WITH ATTRIBUTE-SYNTAX NotificationExtensionsSubField MATCHES FOR EQUALITY MULTI VALUE ::= id-nat-notification-extensions An MS that supports one of these attributes shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an EDIN that contains the field or sub-field whose name the attribute bears. 18.7.5.2 Positive Notification fields Some attributes bear the names of PN EDIN fields and have those fields as their values. Some attributes bear the names of notification fields and have sub-fields of the PN fields of a notification as their values. See for semantics. vapn-supplementary-information ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDISupplementaryInformation MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-nat-pn-supplementary-info vapn-extensions ATTRIBUTE WITH ATTRIBUTE-SYNTAX PNExtensionsSubField MATCHES FOR EQUALITY MULTI VALUE ::= id-nat-pn-extensions ATTRIBUTE WITH ATTRIBUTE-SYNTAX FNExtensionsSubField MATCHES FOR EQUALITY MULTI VALUE ::= id-nat-fn-extensions An MS that supports one of these attributes shall maintain it for an information object that it holds if, and only if, that object is a message whose content is an FN that contains the field whose name the attribute bears. It shall maintain one attribute value for each field or sub-field. 18.8 Procedures for EDI MS The procedures for a general MS are specified in 14 and 15 of Recommendation X.413. This reference gives complementary information for MS systems that also explicitly support EDI messaging. 18.8.1 Additional procedures for message delivery How the MS consumes the MTS abstract service is described in 14 of Recommendation X.413. The following text describes additional information about the procedures needed for EDI messaging. If EDI Security Requests are present, then the EDI-auto-forward actions defined above may be prohibited, subject to the security policy in force. If EDI Security Requests are present then the EDI-auto-forward action (forwarding-with-responsibility-accepted) shall not be performed. Addition to 14.1.1 bullet 2) a) of Recommendation X.413: - If EDI auto forwarding criteria are registered by the Register-MS abstract operation, the new entry shall be matched against the criteria registered. The matching shall always proceed starting with the registration having the lowest registration identifier and perform the following auto actions: - registratio s against the "forward-with-responsibility- accepted" auto action. If this results in forwarding being performed, it is possible that one or several forwardings may be performed for this EDIM. registrations against "forward-with-responsibilty-not- accepted" auto-action. If this results in a forwarding being performed, no further EDI forwarding actions shall be performed for this EDIM by the same EDI-MS. d deleted after forwarding, no further forwarding auto-action can take place. The appropriate notification shall be returned for the first auto forwarding that is performed for the EDIM. When an EDIN is submitted, a value reflecting the type of the EDIN shall be added to the "edi-notification-indicator" attribute. If an EDI auto-forwarding does not succee , eg. through a non- delivery, an NN EDIN may be returned to the originator if an FN was previously sent. 19. Message Contents As has already been seen, various secondary objects (e.g., UAs) have occasion to convey the Information Objects of as the contents of messages, as well as to convey probes concerning such messages. What follows specifies precisely how they shall do this. The rules governing the transmittal of such messages and probes, and the semantics and abstract and transfer syntaxes of their contents, constitute glEDI Messaginggl:EDI Messaging. 19.1 Content A secondary object that submits a message containing an EDIM or EDIN shall supply, as the octets of the Octet String that constitutes the content of the message, the result of encoding the Information Object of in accordance with the Basic Encoding Rules of Recommendation X.209. 19.2 Content Type A secondary object that submits a message containing an EDIM or EDIN shall assign either the object identifier id-mct-pedi (see Annex A) or the integer value 35 to the Content Type. The object identifier shall be used if the MTA conforms to Recommendation X.411 in its 1988 version. A secondary object that receives a message containing an EDIM or EDIN shall accept both the object identifier id-mct-pedi and the integer value 35 as Content Type. Notwithstanding the provisions of Annex B of Recommendation X.419, an MTA that conforms to Recommendation X.411 in its 1988 version shall obey the following rules when it relays an MTS-APDU to an MTA that conforms to Recommendation X.411 in its 1984 version: - If the Content Type in a message or probe is indicated by the integer value 35, it shall be unchanged. - If the Content Type in a message containing an EDIM or EDIN is indicated by the object identifier id-mct-pedi, it shall be replaced by the integer value 35. NOTE - When an MTA that conforms to Recommendation X.411 in its 1984 version relays an MTS-APDU to an MTA that conforms to Recommendation X.411 in its 1988 version, and the Content Type contains the integer value 35, the MTA that conforms to Recommendation X.411 in its 1988 version may replace the integer value 35 in the Content Type with the object identifier id-mct-pedi or leave the integer value unchanged. 19.3 Content Length A secondary object that submits a probe concerning a message containing an EDIM or EDIN shall specify as the length of the message's content the size in octets of the encoding of the instance in question of the Information Object of (a choice of an EDIM or an EDIN) when the Basic Encoding Rules of Recommendation X.209 are followed. If those rules permit several (e.g., both primitive and constructed) encoding of that Information Object, the content length may reflect any one of them. 19.4 Encoded Information Types A secondary object that submits a message containing an EDIM or EDIN shal the glEncoded Information Types (abEIT) of the message as follows. In the case of an EDIN, the basic EITs shall be unspecified. In the case of an EDIM, the EITs shall be the logical union of the EITs of the EDIM's body parts specified in accordance with the following rules: a) EDI Body Part: The EIT (if any) of the EDI Body Part shall have the same values as the Heading field EDI Body Part Type. b) EDIM Body Part(Forwarded Message): The EITs (if any) of a EDIM Body Part shall be those of the forwarded message. c) Additional body parts: The EIT of additional body parts (if any) shall be the logical union of the individual body parts EITs. An Externally Defined body part whose extended type corresponds to a basic type shall be indicated using the built-in EIT. The EDI Body Part Type may be indicated in the external EITs. A secondary object that submits a message containing an EDIM to an MTA that conforms to Recommendation X.411 in its 1988 version shall use the union of the object identifiers from EDI Body Part Type (see and Annex A) for all "original-encoded-information-types". " "undefined" bit of the "built-in-encoded-information-types" (called "basic encoded-information-type" in Recommendation X.411 in its 1984 version), as no other indication is possible for the EITs defined in in an MTA that conforms to Recommendation X.411 in its 1984 version. The "external-encoded information-type" field shall not be present. NOTE - The following reduced functionality has to be considered when a secondary object submits a message containing an EDIM to an MTA that conforms to Recommendation X.411 in its 1984 version or when such messages are relayed through such an MTA. The delivering MTA cannot make a comparison of which EITs, and hence primary EDI body part types, the UA is prepared to accept for delivery (otherwise it would not perform the delivery at all). In addition, the security features of an MTA that conforms to Recommendation X.411 in its 1988 version cannot be used. 20. Port realization How an MS or the MTS concretely realizes the secondary ports it supplies is specified in Recommendation X.419. How a UA, TLMA, or AU concretely realizes the primary ports it supplies is beyond the scope of this Recommendation. 21. Conformance The requirements a secondary object (excluding the MTS) and its implementor shall meet when the latter claims the former's conformance to this Recommendation are identified below. A number of the conformance requirements distinguish between support upon origination and support upon reception. 21.1 Origination versus Reception A UA or AU shall be said to glsu upon origination a particular Heading field, Heading extension, EDIM Body Part type or Externally Defined Body Part type if, and only if, it accepts, preserves, and emits, in full accord with this Recommendation, that particular Heading field or extension, or EDIM Body Part type or Externally Defined Body Part type, whenever a user calls upon it to convey an EDIM containing them to the MTS or the user's MS (the latter only in the case of a UA). A UA or AU shall be said to glsupport n reception a particular Heading field, Heading extension, EDIM Body Part type or Externally Defined Body Part type if, and only if, it accepts, preserves, and emits, in full accord with this Recommendation, that particular Heading field or extension, or EDIM Body Part type or Externally Defined Body Part type, whenever the MTS or a user's MS (the latter only in the case of a UA) calls upon it to convey to the user an EDIM containing them. A PDAU supports nothing upon origination because it is not a supplier of the origination port. 21.2 Statement requirements The implementor of a UA, MS or AU shall state the following. For each item below he shall make separate statements concerning conformance upon origination and conformance upon reception: a) The Heading fields for which he claims conformance. b) The body part types for which he claims conformance. c) In the case of a UA with MS or MS, the EDI Messaging-specific MS attributes for which it claims conformance. d) In the case of a UA with MS or MS, whether is supports the EDI messaging-specific auto actions. 21.3 Static requirements A UA, MS or AU shall satisfy the following static requirements: a) A UA, MS or AU shall implement the Heading fields and the body part types for which conformance is claimed. b) A UA with MS or MS shall support the EDI messaging-specific MS attributes for which conformance is claimed, but including as a minimum those designated mandatory in . In addition, it shall support the mandatory attributes identified in Table 1 of Recommendation X.413. c) A UA, MS or AU shall concretely realize its abstract ports as specified in . d) A UA or MS shall be able to both submit and receive messages of the content types of . An AU shall be able to both import and export such messages. 21.4 Dynamic requirements A UA, MS or AU shall satisfy the following dynamic requirements: a) A UA or MS shall follow the rules of operation specified in or , respectively. b) A UA, MS or AU shall submit and receive messages whose contents are as specified in . c) A UA, MS or AU shall register with the MTS its ability to accept delivery of messages of both of the content types of and EITs as specified in . ANNEX A Reference definition of Object Identifiers (This annex forms an integral part of this Recommendation.) The annex defines for reference purposes various Object Identifiers cited in the ASN.1 modules of subsequent annexes. It uses ASN.1. All Object Identifiers this Recommendation assigns are assigned in this annex. The annex is definitive for all but those for ASN.1 modules, the object EDIMS application (EDIME) itself and the EDI use of Directories. The definitive assignments for the former occur in the modules themselves; other references to them appear in IMPORT statements. For the EDI use of Directories object identifiers, this annex only defines a base object identifier. ---------- moEDIMSObjectIdentifiers {joint- iso-ccitt mhs-motis(6) edims(7) modules(0) object- identifiers(0) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- Prologue -- Exports everything IMPORTS -- nothing --; tyID ::= OBJECT IDENTIFIER -- EDI Messaging (definitive) idid-edims ID ::= { joint-iso-ccitt mhs- motis(6) edims(7) } -- This is definitive -- Categories idid-mod ID ::= {id-edims 0} -- modules idid-edi ID ::= {id-edims 1} -- reserved idid-ot ID ::= {id-edims 2} -- object types idid-pt ID ::= {id-edims 3} -- port types idid-re ID ::= {id-edims 4} -- refinements idid-sat ID ::= {id-edims 5} -- summary attributes idid-hat ID ::= {id-edims 6} -- heading attributes idid-rat ID ::= {id-edims 7} -- recipient attributes idid-bat ID ::= {id-edims 8} -- body attributes idid-nat ID ::= {id-edims 9} -- notification attributes idid-mct ID ::= {id-edims 10} -- message content types idid-bp ID ::= {id-edims 11} -- edi body part types idid-nt ID ::= {id-edims 12} -- edi notification types idid-for ID ::= {id-edims 13} -- edi action indicator types idid-act ID ::= {id-edims 14} -- edi auto- action indentifier types idid-dir ID ::= {id-edims 15} -- edi use of directories idid-syn ID ::= {id-edims 16} -- edi synopsis type -- Modules idid-mod-object-identifiers ID ::= {id-mod 0} -- definitive idid-mod-functional-objects ID ::= {id-mod 1} -- definitive idid-mod-information-objects ID ::= {id-mod 2} -- definitive idid-mod-abstract-service ID ::= {id-mod 3} -- definitive idid-mod-message-store-attributes ID ::= {id-mod 4} -- definitive idid-mod-upper-bounds ID ::= {id- mod 5} -- definitive idid-mod-edi-directory-cl-att ID ::= {id-mod 6} -- definitive idid-mod-message-store-auto-actions ID ::= {id-mod 7} -- definitive -- Object types idid-ot-edime ID ::= {id-ot 0} idid-ot-edimg-user ID ::= {id-ot 1} idid-ot-edims ID ::= {id-ot 2} idid-ot-edi-ua ID ::= {id-ot 3} idid-ot-edi-ms ID ::= {id-ot 4} idid-ot-pdau ID ::= {id-ot 5} -- Port types idid-pt-origination ID ::= {id-pt 0} idid-pt-reception ID ::= {id-pt 1} -- Refinements idid-ref-primary ID ::= {id-ref 0} idid-ref-secondary ID ::= {id-ref 1} -- EDI-Notification Types (for use in P1 notification extension field) idid-nt-edi-pn ID ::= {id-nt 0} idid-nt-edi-nn ID ::= {id-nt 1} idid-nt-edi-fn ID ::= {id-nt 2} -- Message content type idid-mct-pedi ID ::= {id-mct 0} -- Pedi -- EDI Body Part type (and P1 EIT) idid-edifact-ISO646 ID ::= {id-bp 0} -- ISO646 is equivalent to CCITT T.50 idid-edifact-T61 ID ::= {id-bp 1} idid-edifact-octet ID ::= {id-bp 2} idid-ansiX12-ISO646 ID ::= {id-bp 3} idid-ansiX12-T61 ID ::= {id-bp 4} idid-ansiX12-octet ID ::= {id-bp 5} idid-ansiX12-ebcdic ID ::= {id-bp 6} idid-untid-ISO646 ID ::= {id-bp 7} idid-untid-T61 ID ::= {id-bp 8} idid-untid-octet ID ::= {id-bp 9} idid-private-octet ID ::= {id-bp 10} idid-undefined-octet ID ::= {id- bp 11} -- EDI Action Indication idid-for-action ID ::= {id-for 0} -- For action idid-for-copy ID ::= {id-for 1} -- copy, not original -- EDIMG Specific Register Auto Actions idid-act-edi-auto-forward ID ::= {id-act 0} -- EDIM Synopsis (MS) idid-syn-removed ID ::= {id-syn 0} idid-syn-place-holder ID ::= {id- syn 1} -- MESSAGE STORE ATTRIBUTES -- Summary attributes idid-sat-edims-entry-type ID ::= {id-sat 0} idid-sat-edim-synopsis ID ::= {id- sat 1} idid-sat-edi-notification-indicator ID ::= {id-sat 2} -- Heading attributes ha hat 4} idid-hat-responsibility-forwardedid:id-hat-responsibility- forwarded ID ::= {id-hat 5} idid-hat-edi-bodypart-typeid:id-hat-edi-bodypart-type ID ::= {id-hat 6} idid-hat-incomplete-copyid:id-hat-incomplete-copy ID ::= {id-hat 7} idid-hat-expiry-timeid:id-hat-expiry-time ID ::= {id- hat 8} idid-hat-related-messagesid:id-hat-related-messages ID ::= {id-hat 9} idid-hat-obsoleted-edimsid:id-hat-obsoleted-edims ID ::= {id-hat 10} idid-hat-edi-application-security-elementid:id-hat-edi- application-security-element ID ::= {id-hat 11} idid-hat-edi-application-security-extensionsid:id-hat-edi- application-security-extensions ID ::= {id-hat 12} idid-hat-cross-referencing-informationid:id-hat-cross- referencing-information ID ::= {id-hat 13} idid-hat-edi-message-typeid:id-hat-edi-message-type ID ::= {id-hat 14} idid-hat-service-string-adviceid:id-hat-service-string- advice ID ::= {id-hat 15} idid-hat-syntax-identifierid:id-hat-syntax-identifier ID ::= {id-hat 16} idid-hat-interchange-senderid:id-hat-interchange-sender ID ::= {id-hat 17} idid-hat-date-and-time-of-preparationid:id-hat-date-and- time-of-preparation ID ::= {id-hat 18} idid-hat-application-referenceid:id-hat-application- reference ID ::= {id-hat 19} idid-hat-heading-extensionsid:id-hat-heading-extensions ID ::= {id-hat 20} -- Per Recipient attributes idid-rat-this-recipientid:id-rat-this-recipient ID ::= {id-rat 10} idid-rat-action-request-for-this-recipientid:id-rat-action- request-for-this-recipient ID ::= {id-rat 1} idid-rat-edi-notification-requests-for-this-recipientid:id- rat-edi-notification-requests-for-this-recipient ID ::= {id-rat 2} idid-rat-responsibility-passing-allowed-for-this- recipientid:id-rat-responsibility-passing-allowed-for-this- recipient ID ::= {id-rat 3} -- UNB EDIFACT Field Object Ids -- idid-rat-interchange-recipient-for-this-recipientid:id-rat- interchange-recipient-for-this-recipient ID ::= {id- rat 4} idid-rat-recipient-reference-for-this-recipientid:id-rat- recipient-reference-for-this-recipient ID ::= {id-rat 5} idid-rat-interchange-control-reference-for-this- recipientid:id-rat-interchange-control-reference-for-this- recipient ID ::= {id-rat 6} idid-rat-processing-priority-code-for-this-recipientid:id- rat-processing-priority-code-for-this-recipient ID ::= {id-hat 7} idid-rat-acknowledgement-request-for-this-recipientid:id- rat-acknowledgement-request-for-this-recipient ID ::= {id-rat 8} idid-rat-communications-agreement-id-for-this- recipientid:id-rat-communications-agreement-id-for-this- recipient ID ::= {id-rat 9} idid-rat-test-indicator-for-this-recipientid:id-rat-test- indicator-for-this-recipient ID ::= {id-rat 10} idid-rat-notification-security-for-this-recipientid:id-rat- notification-security-for-this-recipient ID ::= {id- rat 11} idid-rat-edi-reception-security-for-this-recipientid:id- rat-edi-reception-security-for-this-recipient ID ::= {id-rat 12} idid-rat-recipient-extensions-for-this-recipientid:id-rat- recipient-extensions-for-this-recipient ID ::= {id-rat 13} -- ANSIX12 ISA Field Object Ids -- .I.id:id-rat-authorization-information-for-this- recipient; ID ::= {id-rat 14} -- Body attributes idid-bat-body ID ::= {id-bat 0} idid-bat-interchange-length ID ::= {id-bat 1} idid-bat-edi-body-part ID ::= {id- bat 2} idid-bat-edim-body-part ID ::= {id-bat 3} idid-bat-message-parameters ID ::= {id-bat 4} idid-bat-message-data ID ::= {id- bat 5} idid-bat-externally-defined-body-part-types ID ::= {id-bat 6} -- Notification attributes idid-nat-subject-edim ID ::= {id- nat 0} idid-nat-edin-originator ID ::= {id-nat 1} idid-nat-first-recipient ID ::= {id-nat 2} idid-nat-notification-time ID ::= {id-nat 3} idid-nat-notification-security-elements ID ::= {id-nat 4} idid-nat-notification-extensions ID ::= {id-nat 5} idid-nat-edin-initiator ID ::= {id-nat 6} -- PN attributes idid-nat-pn-supplementary-info ID ::= {id-nat 7} idid-nat-pn-extensions ID ::= {id- nat 8} -- NN attributes idid-nat-nn-reason-code ID ::= {id-nat 9} idid-nat-nn-supplementary-info ID ::= {id-nat 10} idid-nat-nn-extensions ID ::= {id- nat 11} -- FN attributesidid-nat-forwarded-to ID ::= {id- nat 12} idid-nat-fn-reason-code ID ::= {id-nat 13} idid-nat-fn-supplementary-info ID ::= {id-nat 14} idid-nat-fn-extensions ID ::= {id- nat 15} -- MESSAGE STORE ATTRIBUTES - END END -- of EDIMSObjectIdentifiers ANNEX B Reference definition of Abstract Information Objects (This annex forms an integral part of this Recommendation.) obj objects of EDI Messaging. It defines a Body Part for EDIM that includes a body part reference number while importing the IPMS externally defined MACRO for specifying non-EDI body parts. It also defines an EDIM-EXTENSION MACRO that differs from IPMS. mo EDIMSInformationObjectsmo: EDIMSInformationObjects {joint-iso-ccitt mhs-motis(6) edims(7) modules(0) information- objects(2) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- Prologue -- Exports everything IMPORTS -- EDIMS Upper bounds ub-application-reference, ub-authorization-information, ub-authorization-information-qualifier, ub-communications-agreement-id, ub-edi-application-security-elements, ub-edi-message-type, ub-identification-code, ub-identification-code-qualifier, ub-interchange-control- reference, ub-local-reference, ub-processing-priority-code, ub-reason-code, ub-recipient- reference, ub-recipient-reference-qualifier, ub-routing-address, ub-syntax-identifier, ub-syntax-version ---- FROM EDIMSUpperBounds {joint-iso-ccitt mhs-motis(6) edims(7) modules(0) upper- bounds(5) } -- EDIMS Object Identifiers id-edifact-ISO646, id-for-action ----- FROM EDIMSObjectIdentifiers {joint-iso-ccitt mhs-motis(6) edims(7) modules(0) object-identifiers(0) } -- MTS Upper Bounds ub-bit-options, ub-integer-options, ub-supplementary-info-length ---- FROM MTSUpperBounds {joint-iso-ccitt mhs-motis(6) mts(3) modules(0) upper-bounds(3) } -- MTS Abstract Service MessageDeliveryTime, ORAddress, ORName, OtherMessageDeliveryFields, ContentIntegrityCheck ---- FROM MTSAbstractService {joint-iso-ccitt mhs-motis(6) mts(3) modules(0) mts- abstract-service(1) } -- IPM Abstract Service EXTENDED-BODY-PART-TYPE, ExternallyDefinedBodyPart, ---- FROM IPMSInformationObjects {joint-iso-ccitt mhs-motis(6) ipms(1) modules(0) information-objects(2) }; -- END Imports -- ABSTRACT INFORMATION OBJECTS -- Overview tyInformationObject ::= CHOICE { edim [0] EDIM, edin [1] EDIN } -- Common data types -- EDIM Identifier tyEDIMIdentifier ::= SET { user [0] ORName, user-relative-identifier [1] LocalReference } tyLocalReference ::= PrintableString (SIZE (0..ub-local-reference)) -- Extensions tyExtensionField ::= SEQUENCE { type [0] EDIM-EXTENSION, criticality [1] Criticality DEFAULT FALSE, value [2] ANY DEFINED BY type DEFAULT NULL NULL } tyCriticality ::= BOOLEAN -- EDIM Extension MACRO maEDIM-EXTENSION MACRO ::= BEGIN TYPE NOTATION ::= DataType Critical | empty VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) DataType ::= type (X) Default | empty Default ::= "DEFAULT" value (X) | empty Critical ::= "CRITICAL" | empty END -- of extension -- EDI Messages tyEDIM ::= SEQUENCE { heading Heading, body Body } -- Heading Field Component Types -- Interchange Recipient / Sender -- Identification Code tyIdentificationCode ::= T61String (SIZE (1..ub-identification-code)) -- Identification Code Qualifier tyIdentificationCodeQualifier ::= T61String (SIZE (1..ub-identification-code- qualifier)) -- Routing Address tyRoutingAddress ::= T61String (SIZE (1..ub-routing-address)) -- Heading Fields tyHeading ::= SEQUENCE { this-EDIM [1] ThisEDIMField, originator [2] OriginatorField OPTIONAL, recipients [3] RecipientsField OPTIONAL, edin-receiver [4] EDINReceiverField OPTIONAL, responsibility-forwarded [5] ResponsibilityForwarded DEFAULT FALSE, edi-bodypart-type [6] EDIBodypartType DEFAULT {id- edifact-ISO646}, incomplete-copy [7] IncompleteCopyField DEFAULT FALSE, expiry-time [8] ExpiryTimeField OPTIONAL, related-messages [9] RelatedMessagesField OPTIONAL, obsoleted-EDIMs [10] ObsoletedEDIMsField OPTIONAL, edi-application-security-elements [11] EDIApplicationSecurityElementsField OPTIONAL cross-referencing-information [12] CrossReferencingInformationField OPTIONAL, -- Begin Fields from EDIFACT Interchange edi-message-type [13] EDIMessageTypeField OPTIONAL, service-string-advice [14] ServiceStringAdviceField OPTIONAL, syntax-identifier [15] SyntaxIdentifierField OPTIONAL, interchange-sender [16] InterchangeSenderField OPTIONAL, date-and-time-of-preparation [17] DateAndTimeOfPreparationField OPTIONAL, application-reference [18] ApplicationReferenceField OPTIONAL, -- End Fields from EDIFACT heading-extensions [19] HeadingExtensionsField OPTIONAL } -- This EDIM tyThisEDIMField ::= EDIMIdentifier -- Originator tyOriginatorField ::= ORName -- Recipients Recipien RecipientsSubField c016 tyRecipientsSubFieldty:RecipientsSubField ::= SEQUENCE { recipient [1] RecipientField, action-request [2] ActionRequestField DEFAULT {id- for-action}, edi-notification-requests-field [3] EDINotificationRequestsField OPTIONAL, responsibility-passing-allowed [4] ResponsibilityPassingAllowedField DEFAULT FALSE, -- Begin Fields from EDIFACT UNB interchange-recipient [5] InterchangeRecipientField OPTIONAL, recipient-reference [6] RecipientReferenceField OPTIONAL, interchange-control-reference [7] InterchangeControlReferenceField OPTIONAL, processing-priority-code [8] ProcessingPriorityCodeField OPTIONAL, acknowledgement-request [9] AcknowledgementRequestField DEFAULT FALSE, communications-agreement-id [10] CommunicationsAgreementIdField OPTIONAL, test-indicator [11] TestIndicatorField DEFAULT FALSE, -- End Fields from EDIFACT UNB -- Begin Fields from ANSIX12 ISA authorization-information [12] AuthorizationInformationField OPTIONAL, -- End Fields from ANSIX12 ISA recipient-extensions [13] RecipientExtensionsField OPTIONAL } -- Recipient c017 tyRecipientFieldty:RecipientField ::= ORName -- Action Request c018 tyActionRequestFieldty:ActionRequestField ::= OBJECT IDENTIFIER -- EDI Notification Requests c019 tyEDINotificationRequestsFieldty:EDINotificationRequests Field ::= SEQUENCE { edi-notification-requests [0] EDINotificationRequests DEFAULT {}, edi-notification-security [1] EDINotificationSecurity DEFAULT {}, edi-reception-security [2] EDIReceptionSecurity DEFAULT {} } tyEDINotificationRequeststy:EDINotificationRequests ::= BIT STRING { pn (0), nn (1), fn (2) }(SIZE (0..ub-bit-options)) BIT BIT STRING { proof (0), non-repudiation (1) } (SIZE (0..ub-bit-options)) tyEDIReceptionSecurityty:EDIReceptionSecurity ::= BIT STRING { proof (0), non-repudiation (1) }(SIZE (0..ub-bit-options)) -- Interchange recipient c021 tyInterchangeRecipientFieldty:InterchangeRecipientField ::= SEQUENCE { recipient-identification-code [0] IdentificationCode, identification-code-qualifier [1] IdentificationCodeQualifier OPTIONAL, routing-address [2] RoutingAddress OPTIONAL } -- Recipient reference c022 tyRecipientReferenceFieldty:RecipientReferenceField ::= SEQUENCE { recipient-reference [0] RecipientReference, recipient-reference-qualifier [1] RecipientReferenceQualifier OPTIONAL } tyRecipientReferencety:RecipientReference ::= T61String (SIZE (1..ub-recipient-reference)) tyRecipientReferenceQualifierty:RecipientReferenceQualifie r ::= T61String (SIZE (1..ub-recipient-reference- qualifier)) -- Recipient Extensions c023 tyRecipientExtensionsFieldty:RecipientExtensionsField ::= SET OF RecipientExtensionsSubField tyRecipientExtensionsSubFieldty:RecipientExtensionsSubFiel d ::= ExtensionField -- EDIN receiver c024 tyEDINReceiverFieldty:EDINReceiverField ::= SEQUENCE { edin-receiver-name [0] ORName, original-edim-identifier [1] EDIMIdentifier OPTIONAL, first-recipient [2] FirstRecipientField OPTIONAL} -- Responsibility Forwarded indication c025 tyResponsibilityForwardedty:ResponsibilityForwarded ::= BOOLEAN -- Default False -- EDI Body Part Types - identifies EDI Standard, Character set and encoding c026 tyEDIBodyPartTypety:EDIBodyPartType ::= OBJECT IDENTIFIER -- default EDIFACT-ISO646 -- EDI message type tyEDIMessageTypeField ::= SET OF EDIMessageTypeFieldSubField tyEDIMessageTypeFieldSubField ::= T61String (SIZE (1..ub-edi-message-type)) -- Responsibility Passing Allowed tyResponsibilityPassingAllowedField ::= BOOLEAN -- Default FALSE -- Incomplete Copy tyIncompleteCopyField ::= BOOLEAN -- Default False -- Expiry time tyExpiryTimeField ::= UTCTime -- Related Messages tyRelatedMessagesField ::= SEQUENCE OF RelatedMessageReference tyRelatedMessageReference ::= CHOICE { edi-message-reference [0] EDIMIdentifier, external-message-reference [1] ExternalMessageReference } tyExternalMessageReference ::= EXTERNAL -- Obsoleted EDIMs tyObsoletedEDIMsField ::= SEQUENCE OF ObsoletedEDIMsSubfield tyObsoletedEDIMsSubfield ::= EDIMIdentifier -- EDI Application Security Elements tyEDIApplicationSecurityElementsField ::= SEQUENCE { edi-application-security-element [0] EDIApplicationSecurityElement OPTIONAL, edi-encrypted-primary-bodypart [1] BOOLEAN OPTIONAL, edi-application-security-extensions [2] EDIApplicationSecurityExtensions OPTIONAL } tyEDIApplicationSecurityElement ::= BIT STRING (SIZE (0..ub-edi-application-security- elements)) tyEDIApplicationSecurityExtensions ::= SEQUENCE OF EDIApplicationSecurityExtension : ::= ExtensionsField -- Cross Referencing Information c036 tyCrossReferencingInformationFieldty:CrossReferencingInf ormationField ::= SET OF CrossReferencingInformationSubField tyCrossReferencingInformationSubFieldty:CrossReferencingIn formationSubField ::= SEQUENCE { application-cross-reference [0] ApplicationCrossReference, message-reference [1] MessageReference OPTIONAL, body-part-reference [2] BodyPartReference } tyApplicationCrossReferencety:ApplicationCrossReference ::= OCTET STRING tyMessageReferencety:MessageReference ::= EDIMIdentifier -- Service String Advice c037 tyServiceStringAdviceFieldty:ServiceStringAdviceField ::= SEQUENCE { component-data-element-separator [0] ComponentDataElementSeparator, data-element-separator [1] DataElementSeparator, decimal-notation [2] DecimalNotation, release-indicator [3] ReleaseIndicator OPTIONAL, reserved [4] Reserved OPTIONAL, segment-terminator [5] SegmentTerminator } tyComponentDataElementSeparatorty:ComponentDataElementSepa rator ::= OCTET STRING (SIZE (1)) tyDataElementSeparatorty:DataElementSeparator ::= OCTET STRING (SIZE (1)) tyDecimalNotationty:DecimalNotation ::= OCTET STRING (SIZE (1)) tyReleaseIndicatorty:ReleaseIndicator ::= OCTET STRING (SIZE (1)) tyReservedty:Reserved ::= OCTET STRING (SIZE (1)) tySegmentTerminatorty:SegmentTerminator ::= OCTET STRING (SIZE (1)) -- Syntax Identifier c038 tySyntaxIdentifierFieldty:SyntaxIdentifierField ::= SEQUENCE { syntax-identifier SyntaxIdentifier, syntax-version SyntaxVersion } tySyntaxIdentifierty:SyntaxIdentifier ::= T61String (SIZE (1..ub-syntax-identifier)) tySyntaxVersionty:SyntaxVersion ::= PrintableString (SIZE (1..ub-syntax-version)) -- Interchange sender tyInterchangeSenderField ::= SEQUENCE { sender-identification [0] IdentificationCode, identification-code-qualifier [1] IdentificationCodeQualifier OPTIONAL, address-for-reverse-routing [2] RoutingAddress OPTIONAL } -- EDIFACT Routing Information -- Date and Time of preparation tyDateAndTimeOfPreparationField ::= UTCTime -- Interchange control reference tyInterchangeControlReferenceField ::= T61String (SIZE (1..ub-interchange- control-reference)) -- Application reference tyApplicationReferenceField ::= T61String (SIZE (1..ub-application-reference)) -- Processing Priority Code tyProcessingPriorityCodeField ::= T61String (SIZE (1..ub-processing-priority- code)) -- Acknowledgement Request tyAcknowledgementRequestField ::= BOOLEAN -- default FALSE -- Communications Agreement Id tyCommunicationsAgreementIdField ::= T61String (SIZE (1..ub-communications- agreement-id)) -- Test indicator tyTestIndicatorField ::= BOOLEAN -- default FALSE -- Authorization Information tyAuthorizationInformationField ::= SEQUENCE { authorization-information [0] AuthorizationInformation, authorization-information-qualifier [1] AuthorizationInformationQualifier OPTIONAL } tyAuthorizationInformation ::= T61String (SIZE (1..ub-authorization-information)) tyAuthorizationInformationQualifier ::= T61String (SIZE (1..ub-authorization- information-qualifier)) -- Heading Extensions tyHeadingExtensionsField ::= SET OF HeadingExtensionsSubField ::= ::= ExtensionField -- EDIM body c008 tyBodyty:Body ::= SEQUENCE { primary-body-part PrimaryBodyPart, additional-body-parts OtherBodyParts OPTIONAL } tyPrimaryBodyPartty:PrimaryBodyPart ::= CHOICE { edi-body-part [0] EDIBodyPart, forwarded-EDIM [1] EDIMBodyPart } tyOtherBodyPartsty:OtherBodyParts ::= SEQUENCE OF EDIM- ExternallyDefinedBodyPart -- EDI body part c049 tyEDIBodyPartty:EDIBodyPart ::= OCTET STRING -- Forwarded EDIM body part c050 tyEDIMBodyPartty:EDIMBodyPart ::= SEQUENCE { parameters [0] MessageParameters OPTIONAL, data [1] MessageData } tyMessageParametersty:MessageParameters ::= SET { delivery-time [0] MessageDeliveryTime OPTIONAL, delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL, other-parameters [2] EDISupplementaryInformation OPTIONAL } tyMessageDataty:MessageData ::= SEQUENCE { heading Heading, body BodyOrRemoved } tyBodyOrRemovedty:BodyOrRemoved ::= SEQUENCE { primary-or-removed PrimaryOrRemoved, additional-body-parts AdditionalBodyParts OPTIONAL } tyPrimaryOrRemovedty:PrimaryOrRemoved ::= CHOICE { removed-edi-body [0] NULL, primary-body-part [1] EXPLICIT PrimaryBodyPart } tyAdditionalBodyPartsty:AdditionalBodyParts ::= SEQUENCE OF CHOICE { external-body-part [0] EDIM- ExternallyDefinedBodyPart, place-holder [1] BodyPartPlaceHolder } -- This type is for Body Part Removal tyBodyPartPlaceHolderty:BodyPartPlaceHolder ::= EDIM- ExternallyDefinedBodyPart -- Only the data -- portion of the Externally Defined Body shall be removed. -- See text in . -- EDIM Externally Defined Body Parts c05 tyEDIM-ExternallyDefinedBodyPartty:EDIM- ExternallyDefinedBodyPart ::= SEQUENCE { body-part-reference [0] BodyPartReference OPTIONAL, external-body-part [1] ExternallyDefinedBodyPart -- from IPMS --} tyBodyPartReference ::= INTEGER -- shall be unique within a EDIM -- Supplementary Info tyEDISupplementaryInformation ::= IA5String (SIZE (1..ub-supplementary-info- length)) -- EDI Notifications (EDINs) tyEDIN ::= CHOICE { positive-notification [0] PositiveNotificationFields, negative-notification [1] NegativeNotificationFields, forwarded-notification [2] ForwardedNotificationFields } tyPN ::= EDIN -- with positive-notification chosen tyNN ::= EDIN -- with negative-notification chosen tyFN ::= EDIN -- with forwarded-notification chosen -- Common fields tyCommonFields ::= SEQUENCE { subject-edim [1] SubjectEDIMField, edin-originator [2] EDINOriginatorField, first-recipient [3] FirstRecipientField OPTIONAL, notification-time [4] NotificationTimeField, notification-security-elements [5] SecurityElementsField OPTIONAL, edin-initiator [6] EDINInitiatorField, notifications-extensions [7] NotificationExtensionsField OPTIONAL } -- Subject EDIM Identifier tySubjectEDIMField ::= EDIMIdentifier -- EDI Notification Originator tyEDINOriginatorField ::= ORName -- First Recipient tyFirstRecipientField ::= ORName -- Notification Time tyNotificationTimeField ::= UTCTime -- Security Elements tySecurityElementsField ::= SEQUENCE { original-content [0] Content OPTIONAL, original-content-integrity-check [1] ContentIntegrityCheck OPTIONAL, edi-application-security-elements [2] EDIApplicationSecurityElementsField OPTIONAL, security-extensions [3] SecurityExtensionsField OPTIONAL } tySecurityExtensionsField ::= SET OF SecurityExtensionsSubField tySecurityExtensionsSubField ::= ExtensionField -- EDIN Initiator tyEDINInitiatorField ::= ENUMERATED { internal-ua (0), external-ua (1), internal-ms (2)} -- Notification Extensions tyNotificationExtensionsField ::= SET OF NotificationExtensionsSubField tyNotificationExtensionsSubField ::= ExtensionField -- Positive Notification fields tyPositiveNotificationFields ::= SEQUENCE { pn-common-fields [0] CommonFields, pn-supplementary-information [1] EDISupplementaryInformation OPTIONAL, pn-extensions [2] PNExtensionsField OPTIONAL } -- Positive Notification Extensions tyPNExtensionsField ::= SET OF PNExtensionsSubField tyPNExtensionsSubField ::= ExtensionField -- Negative notification fields tyNegativeNotificationFields ::= SEQUENCE { nn-common-fields [0] CommonFields, nn-reason-code [1] NNReasonCodeField, nn-supplementary-information [2] EDISupplementaryInformation OPTIONAL, nn-extensions [3] NNExtensionsField OPTIONAL } -- Negative Notification Reason Codes tyNNReasonCodeField ::= CHOICE { nn-ua-ms-reason-code [0] NNUAMSReasonCodeField, nn-user-reason-code [1] NNUserReasonCodeField, nn-pdau-reason-code [2] NNPDAUReasonCodeField } -- Negative Notification Reason Codes from an EDI-UA or EDI-MS tyNNUAMSReasonCodeField ::= SEQUENCE { nn-ua-ms-basic-code [0] NNUAMSBasicCodeField, nn-ua-ms-diagnostic [1] NNUAMSDiagnosticField OPTIONAL } -- Negative Notification Basic Reason Codes from an EDI-UA or EDI-MS. These codes are -- those specified in Annex B of Recommendation F.435 -- for the element of service "EDI Notification Request". tyNNUAMSBasicCodeField ::= INTEGER{ ecunspecified (0), eccannot-deliver-to-user (1), -- the EDI Interchange can not be passed on to the user ecdelivery-timeout (2), -- the EDI Interchange could not be passed on to the user within -- a specified time limit ecmessage-discarded (3), -- the UA/MS discarded the message before handoff to user ecsubscription-terminated (4), -- recipient's subscription terminated after delivery but before -- handoff to user ecforwarding-error (5), -- EDI Forwarding was attempted, but failed. ecsecurity-error (6) -- security error -- physical delivery errors indicated by "cannot- deliver-to-user" } (0..ub-reason-code) -- Negative Notification Diagnostic Codes from an EDI-UA or EDI-MS tyNNUAMSDiagnosticField ::= INTEGER { -- This field may be used to further specify the error signalled in nn-ua-ms-basic-code - Additional information may be indicated in nn- supplementary-information -- general diagnostic codes ecprotocol-violation (1), -- used if the UA detects a protocol error ecedim-originator-unknown (2), ecedim-recipient-unknown (3), ecedim-recipient-ambiguous (4), -- used if the EDIM recipients or originator are not valid ecaction-request-not-supported (5), -- used when the action requested by the recipient is not performed ecedim-expired (6), -- used when the expiry date of the received EDIM occurred before the subject EDIM -- was successfully passed to the user or forwarded by the EDI-UA ecedim-obsoleted (7), -- used when the EDIM Identifier of the received EDIM was contained in the Obsoleted EDIM field -- of a previously received EDIM. ecduplicate-edim (8), -- used when the same EDIM is received more than once from the same originator ecunsupported-extension (9), -- used if the EDIM contains an extension which is not supported by the UA ecincomplete-copy-rejected (10), -- used if the EDI-UA does not accept EDIMs with the Incomplete Copy Indication true ecedim-too-large-for-application (11), -- used if the EDIM cannot be delivered to the user due to length constraints -- forwarding error diagnostic codes ecforwarded-edim-not-delivered (12), -- used when an Non-Delivery Report is received for forwarded EDIM ecforwarded-edim-delivery-time-out (13), -- used when no Delivery Report is received within a given period ecforwarding-loop-detected (14), -- used if the UA receives an EDIM wich contains a previously forwarded EDIM ecunable-to-accept-responsibility (15), -- used if the EDI-UA cannot accept or forward responsibility -- interchange header diagnostic codes ecinterchange-sender-unknown (16), -- used when the UA does not recognizes the interchange-sender of the EDI interchange ecinterchange-recipient-unknown (17), -- used when the UA cannot find a valid interchange recipient in the Recipient Specifier ecinvalid-heading-field (18), ecinvalid-bodypart-type (19), ecinvalid-message-type (20), ecinvalid-syntax-id (21), -- security error diagnostic codes ecmessage-integrity-failure (22), ecforwarded-message-integrity-failure (23), ecunsupported-algorithm (24), ecdecryption-failed (25), ectoken-error (26), ecunable-to-sign-notification (27), ecunable-to-sign-message-receipt (28), ecauthentication-failure (29), ecsecurity-context-failure (30), ecmessage-sequence-failure (31), ecmessage-security-labelling-failure (32), ecrepudiation-failure (33), ecproof-of-failure (34) } (1..ub-reason-code) -- Negative Notification Reason Codes from a user tyNNUserReasonCodeField ::= SEQUENCE { nn-user-basic-code [0] NNUserBasicCodeField, nn-user-diagnostic [1] NNUserDiagnosticField OPTIONAL } -- Negative Notification Basic Reason Codes from a user tyNNUserBasicCodeField ::= INTEGER { ecunspecified (0), ecsyntax-error (1), -- used when the user discovers a syntax error within the EDI interchange ecinterchange-sender-unknown (2), ecinterchange-recipient-unknown (3), -- used when the UA cannot find a valid interchange recipient in the Recipient Specifier ecinvalid-heading-field (4), ecinvalid-bodypart-type (5), ecinvalid-message-type (6), ecfunctional-group-not-supported (7), ecsubscription-terminated (8), -- unknown to EDIMS-User service ecno-bilateral-agreement (9), ecuser-defined-reason (10) } (0..ub-reason-code) -- Negative Notification Diagnostic Reason Codes from a user tyNNUserDiagnosticCodeField ::= INTEGER -- Contains reason passed by user when the value of nn- user-basic-code is user-defined-reason. -- Additional information may be indicated in nn- supplementary-information -- Negative Notification Reason Codes from a PDAU tyNNPDAUReasonCodeField ::= SEQUENCE { nn-pdau-basic-code [0] NNPDAUBasicCodeField, nn-pdau-diagnostic [1] NNPDAUDiagnosticField OPTIONAL } -- Negative Notification Basic Reason Codes from a PDAU tyNNPDAUBasicCodeField ::= INTEGER { ecunspecified (0), ecundeliverable-mail (1), -- used if the PDAU determines that it cannot perform physical delivery of the EDIM ecphysical-rendition-not-performed (2) -- used if the PDAU cannot perform the physical rendition of the EDIM } (0..ub-reason-code) -- Negative Notification Diagnostic Codes from a PDAU tyNNPDAUDiagnosticField ::= INTEGER { -- This field may be used to further specify the error signalled in nn-pdau-basic-code -- Addition l information may be indicated in the nn- supplementary-information ecundeliverable-mail-physical-delivery-address- incorrect (1), ecundeliverable-mail-physical-delivery-office-incorrect- or-invalid (2), ecundeliverable-mail-physical-delivery-address- incomplete (3), ecundeliverable-mail-recipient-unknown (4), ecundeliverable-mail-recipient-deceased (5), ecundeliverable-mail-recipient-refused-to- accept (6), ecundeliverable-mail-organization- expired (7), ecundeliverable-mail-recipient-did-not- claim (8), ecundeliverable-mail-recipient-changed-address- permanently (9), ecundeliverable-mail-recipient-changed-address- temporarily (10), ecundeliverable-mail-recipient-changed-temporary- address (11), ecundeliverable-mail-new-address-unknown (12), ecundeliverable-mail-recipient-did-not-want forwarding (13), ecundeliverable-mail-originator-prohibited- forwarding (14), ecphysical-rendition-attributes-not-supported (15) } (1..ub-reason-code) -- Negative Notification Extension Field(s) tyNNExtensionsField ::= SET OF NNExtensionsSubField tyNNExtensionsSubField ::= ExtensionField -- Forwarded Notification Fields tyForwardedNotificationFields ::= SEQUENCE { fn-common-fields [0] CommonFields, forwarded-to [1] ForwardedTo, fn-reason-code [2] FNReasonCodeField, fn-supplementary-information [3] EDISupplementaryInformation OPTIONAL, fn-extensions [4] FNExtensionsField OPTIONAL } -- Forwarded To tyForwardedTo ::= ORName -- Forwarded Reason Code tyFNReasonCodeField ::= CHOICE { fn-ua-ms-reason-code [0] FNUAMSReasonCodeField, fn-user-reason-code [1] FNUserReasonCodeField, fn-pdau-reason-code [2] FNPDAUReasonCodeFields } -- Forwarding Notification Reason Codes from an EDI-UA or EDI-MS tyFNUAMSReasonCodeField ::= SEQUENCE { fn-ua-ms-basic-code [0] FNUAMSBasicCodeField, fn-ua-ms-diagnostic [1] FNUAMSDiagnosticField OPTIONAL, fn-security-check [2] FNUAMSSecurityCheckField DEFAULT FALSE } -- Forwarding Notification Basic Reason Codes from an EDI-UA or EDI-MS tyFNUAMSBasicCodeField ::= INTEGER { ecunspecified (0), econward-routing (1), -- used whenever the UA decides to re-route the subject EDIM for local reasons ecrecipient-unknown (2), ecoriginator-unknown (3), ecforwarded-by-edi-ms (4) } (0..ub-reason-code) -- Forwarding Notification Diagnostic Reason Codes from an EDI-UA or EDI-MS tyFNUAMSDiagnosticField ::= INTEGER { -- This field may be used to further specify the error signalled in fn-ua-ms-basic-code. -- Additional information may be indicated in fn- supplementary-information. ecrecipient-name-changed (0), ecrecipient-name-deleted (1) } (1..ub-reason-code) -- Forwarding Notification Security Check Codes from an EDI-UA or EDI-MS tyFNUAMSSecurityCheckField ::= BOOLEAN -- Forwarding Notification Reason Codes from a user tyFNUserReasonCodeField ::= SEQUENCE { fn-user-basic-code [0] FNUserBasicCodeField, fn-user-diagnostic [1] FNUserDiagnosticField OPTIONAL } -- Forwarding Notification Basic Reason Codes from a user ty FNUserBasicCodeField ::= INTEGER { ecunspecified (0), ecforwarded-for-archiving (1), ecforwarded-for-information (2), ecforwarded-for-additional-action (3), ecsubscription-changed (4), echeading-field-not-supported (5), ecbodypart-type-not-supported (6), ecmessage-type-not-supported (7), ecsyntax-identifier-not-supported (8), ecinterchange-sender-unknown (9), ecinterchange-sender-unknown (10), ecuser-defined-reason (11) } (0..ub-reason-code) -- Forwarding Notification Diagnostic Reason Codes from a user tyFNUserDiagnosticField ::= INTEGER -- Contains reason passed by user when value of fn-user- basic-code is user-defined-reason. -- Additional information may be indicated in fn- supplementary-information. -- Forwarding Notification Reason Codes from a PDAU tyFNPDAUReasonCodeField ::= SEQUENCE { fn-pdau-basic-code [0] FNPDAUBasicCodeField, fn-pdau-diagnostic [1] FNPDAUDiagnosticField OPTIONAL } -- Forwarding Notification Basic Reason Codes from a PDAU tyFNPDAUBasicCodeField ::= INTEGER { ecunspecified (0), ecforwarded-for-physical-rendition-and- delivery (1) } (0..ub-reason-code) -- Forwarding Notification Diagnostic Reason Codes from a PDAU tyFNPDAUDiagnosticField ::= INTEGER -- Forwarded Notification Extensions tyFNExtensionsField ::= SET OF FNExtensionsSubField tyFNExtensionsSubField ::= ExtensionField END -- of EDIMSInformationObjects ANNEX C Reference definition of Message Store Attributes (This annex forms an integral part of this Recommendation.) This annex defines for reference purposes the MS attributes specific to EDIM Messaging. It uses the ATTRIBUTE macro of Recommendation X.501. ---------- moEDIMSMessageStoreAttributes {joint-iso-ccitt mhs-motis(6) edims(7) modules(0) message-store- attributes(4) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- Prologue -- Exports everything. IMPORTS -- EDIMS Object Identifiers id-bat-body, id-bat-edi-body-part, id-bat-edim-body-part, id-bat-externally-defined-body-part-types id-bat-interchange-length, id-bat- message-data, id-bat-message-parameters id-hat-acknowledgement-request, id-hat-application- reference, id-hat-cross-referencing-information, id-hat-date-and-time-of-preparation, id-hat-edi-application-security-element, id-hat-edi-application-security-extensions, id-hat-edi-bodypart-type, id-hat-edi-message-type, id-hat-edin-receiver, id-hat-expiry-time, id-hat-heading, id-hat-heading-extensions, id-hat-incomplete-copy, id-hat-interchange-sender, id-hat-obsoleted-edims, id-hat-originator, id-hat- processing-priority-code, id-hat-recipients, id-hat-related-messages, id-hat-sensitivity, id-hat-service-string-advice, id-hat-syntax-identifier, id-hat-this-edim, id-nat-edin-originator, id-nat-first-recipient, id-nat-fn- extensions, id-nat-fn-reason-code, id-nat-fn-supplementary-info, id-nat-forwarded-to, id-nat-nn-extensions, id-nat-nn-reason-code, id-nat-nn-supplementary-info, id-nat-notification-extensions, id-nat-notification- security-elements, id-nat-notification-time, id-nat-pn-extensions, id-nat-pn-supplementary-info, id- nat-subject-edim, id-rat-action-request-for-this-recipient, id-rat-authorization-information-for-this- recipient, id-rat-communications-agreement-id-for-this-recipient, id-rat-edi-notification- requests-for-this-recipient, id-rat-edim-reception-security-requests-for-this-recipient, id-rat-interchange-control-reference-for-this-recipient, id-rat-interchange- recipient-for-this-recipient, id-rat-recipient-extensions-for-this-recipient, id-rat-this-recipient, id-rat-recipient-reference-for-this-recipient, id-rat-responsibility-passing-allowed-for-this-recipient, id-rat-test-indicator-for-this-recipient, id-sat-edim-synopsis, id-sat-edims-entry- type ----- FROM EDIMSObjectIdentifiers {joint-iso-ccitt mhs-motis(6) edims(7) modules(0) object-identifiers(0) } -- MS Abstract Service SequenceNumber ---- FROM MSAbstractService {joint-iso-ccitt mhs-motis(6) ms(4) modules(0) abstract- service(1) } -- EDIMS Information Objects AcknowledgementRequestField, ActionRequestField, ApplicationReferenceField, AuthorizationInformationField,Body, BodyPartReference, CommunicationsAgreementIdField, CrossReferencingInformationSubField, DateAndTimeOfPreparationField, EDIApplicationSecuriptyElementsField, EDIBodyPart, EDIBodyPartType, EDIMessageTypeFieldSubField, EDINInitiatorField, EDINOriginatorField, EDINotificationRequestsField, EDINReceiverField, EDISupplementaryInformation, ExpiryTimeField, FirstRecipientField, FNExtensionsSubField, FNReasonCodeField, ForwardedTo, Heading, HeadingExtensionsSubField, IncompleteCopyField, InterchangeControlReferenceField, InterchangeRecipientField, InterchangeSenderField, MessageData, MessageParameters, NNReasonCodeField, NNExtensionsSubField, NotificationExtensionsSubField, NotificationTimeField, ObsoletedEDIMsSubfield, OriginatorField, PositiveNotificationFields, PNExtensionsSubField, ProcessingPriorityCodeField, RecipientExtensionsSubField, RecipientField, RecipientReferenceField, RecipientsSubField, RelatedMessagesField, ResponsibilityForwarded, ResponsibilityPassingAllowedField, SecurityElementsField, ServiceStringAdviceField, SubjectEDIMField, SyntaxIdentifierField, TestIndicatorField, ThisEDIMField ---- FROM EDIMSInformationObjects {joint-iso-ccitt mhs-motis(6) edims(7) modules(0) information-objects(2) } -- IPMS Information Objects ExternallyDefinedParameters ---- FROM IPMSInformationObjects {joint-iso-ccitt mhs-motis(6) ipms(1) modules(0) information-objects(2) } -- Directory Information Framework ATTRIBUTE ---- FROM InformationFramework {joint-iso-ccitt ds(5) modules(1) informationFramework(1) }; -- END imports -- MESSAGE STORE ATTRIBUTES -- Summary Attributes -- EDIMS Entry Type vaedims-entry-type ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDIMSEntryType MATCHES FOR EQUALITY SINGLE VALUE ::= id-sat-edims-entry-type tyEDIMSEntryType ::= ENUMERATED { edim (0), pn (1), nn (2), fn (3) } -- EDIM Synopsis vaedim-synopsis ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDIMSynopsis SINGLE VALUE ::= id-sat-edim-synopsis tyEDIMSynopsis ::= SEQUENCE OF BodyPartSynopsis tyBodyPartSynopsis ::= CHOICE { message [0] MessageBodyPartSynopsis, non-message [1] NonMessageBodyPartSynopsis } tyMessageBodyPartSynopsis ::= SEQUENCE { number [0] SequenceNumber, synopsis [1] EDIMSynopsis } tyNonMessageBodyPartSynopsis ::= SEQUENCE { type [0] OBJECT IDENTIFIER, parameters [1] ExternallyDefinedParameters OPTIONAL, size [2] INTEGER, processed [3] BOOLEAN DEFAULT FALSE } -- EDI Notification Indicator vaedi-notification-indicator ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDINotificationIndicator DEFAULT (0) MATCHES FOR EQUALITY MULTI VALUE ::= id-sat-edi-notification-indicator EDINotificationIndicator ::= ENUMERATED { no-notification-sent (0), pn-sent (1), nn-sent (2), fn-sent (3) } -- Heading Attributes -- Heading vaheading ATTRIBUTE WITH ATTRIBUTE-SYNTAX Heading SINGLE VALUE ::= id-hat-heading -- Heading Fields vathis-edim ATTRIBUTE WITH ATTRIBUTE-SYNTAX ThisEDIMField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-this-edim vaoriginator ATTRIBUTE WITH ATTRIBUTE-SYNTAX OriginatorField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-originator vaedin-receiver ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDINReceiverField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-edin-receiver varesponsibility-forwarded ATTRIBUTE WITH ATTRIBUTE-SYNTAX ResponsibilityForwarded MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-responsibility-forwarded vaedi-bodypart-type ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDIBodyPartType MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-edi-bodypart-type vaincomplete-copy ATTRIBUTE WITH ATTRIBUTE-SYNTAX IncompleteCopyField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-incomplete-copy expiry-time; ATTRIBUTE WITH ATTRIBUTE-SYNTAX ExpiryTimeField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-hat-expiry-time varelated-messages ATTRIBUTE WITH ATTRIBUTE-SYNTAX RelatedMessagesReference MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-related-messages vaobsoleted-edims ATTRIBUTE WITH ATTRIBUTE-SYNTAX ObsoletedEDIMsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-obsoleted-edims vaedi-application-security-element ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDIApplicationSecurityElement MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-edi-application-security-element vaedi-application-security-extensions ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDIApplicationSecurityExtension MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-edi-application-security-extensions vacross-referencing-information ATTRIBUTE WITH ATTRIBUTE-SYNTAX CrossReferencingInformationSubField MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-cross-referencing-information vaedi-message-type ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDIMessageTypeFieldSubField MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-edi-message-type vaservice-string-advice ATTRIBUTE WITH ATTRIBUTE-SYNTAX ServiceStringAdviceField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-service-string-advice vasyntax-identifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX SyntaxIdentifierField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-syntax-identifier vainterchange-sender ATTRIBUTE WITH ATTRIBUTE-SYNTAX InterchangeSenderField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-interchange-sender vadate-and-time-of-preparation ATTRIBUTE WITH ATTRIBUTE-SYNTAX DateAndTimeOfPreparationField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-hat-date-and-time-of-preparation vaapplication-reference ATTRIBUTE WITH ATTRIBUTE-SYNTAX ApplicationReferenceField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-hat-application-reference vaheading-extensions ATTRIBUTE WITH ATTRIBUTE-SYNTAX HeadingExtensionsSubField MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-heading-extensions -- Recipient Sub-field vathis-recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX RecipientField MATCHES FOR EQUALITY SINGLE VALUE ::= id-rat-this-recipient vaaction-request-for-this-recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX ActionRequestField MATCHES FOR EQUALITY SINGLE VALUE ::= id-rat-action-request-for-this-recipient vaedi-notification-requests-for-this-recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDINotificationRequests MATCHES FOR EQUALITY SINGLE VALUE ::= id-rat-edi-notification-requests-for-this-recipient vaedi-notification-security-for-this-recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDINotificationSecurity MATCHES FOR EQUALITY SINGLE VALUE ::= id-rat-edi-notification-security-for-this-recipient vaedi-reception-security-for-this-recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDIReceptionSecurity MATCHES FOR EQUALITY SINGLE VALUE ::= id-rat-edi-reception-security-for-this-recipient varesponsibility-passing-allowed-for-this- recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX ResponsibilityPassingAllowedField MATCHES FOR EQUALITY SINGLE VALUE ::= id-rat-responsibility-passing-allowed-for-this- recipient -- Fields from EDIFACT interchange vainterchange-recipient-for-this-recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX InterchangeRecipientField MATCHES FOR EQUALITY SINGLE VALUE ::= id-rat-interchange-recipient-for-this-recipient varecipient-reference-for-this-recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX RecipientReferenceField MATCHES FOR EQUALITY SINGLE VALUE ::= id-rat-recipient-reference-for-this-recipient vainterchange-control-reference-for-this- recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX InterchangeControlReferenceField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-rat-interchange-control-reference-for-this- recipient vaprocessing-priority-code-for-this-recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX ProcessingPriorityCodeField MATCHES FOR EQUALITY SINGLE VALUE ::= id-rat-processing-priority-code-for-this-recipient vaacknowledgement-request-for-this- recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX AcknowledgementRequestField MATCHES FOR EQUALITY SINGLE VALUE ::= id-rat-acknowledgement-request-for-this-recipient vacommunications-agreement-id-for-this- recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX CommunicationsAgreementIdField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-rat-communications-agreement-id-for-this- recipient vatest-indicator-for-this-recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX TestIndicatorField MATCHES FOR EQUALITY SINGLE VALUE ::= id-rat-test-indication-for-this-recipient -- END Fields from EDIFACT -- Fields from ANSIX12 ISA vaauthorization-information-for-this- recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX AuthorizationInformationField MATCHES FOR EQUALITY SINGLE VALUE ::= id-rat-authorization-information-for-this-recipient -- END Fields from ANSIX12 ISA varecipient-extensions-for-this-recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX RecipientExtensionsSubField MATCHES FOR EQUALITY MULTI VALUE ::= id-rat-recipient-extensions-for-this-recipient -- Body Attributes -- Body vabody ATTRIBUTE WITH ATTRIBUTE-SYNTAX Body SINGLE VALUE ::= id-bat-body -- Body Analyses vainterchange-length ATTRIBUTE WITH ATTRIBUTE-SYNTAX InterchangeLength MATCHES FOR ORDERING SINGLE VALUE ::= id-bat-interchange-length tyInterchangeLength ::= INTEGER -- Primary Body Parts vaedi-body-part ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDIBodyPart SINGLE VALUE ::= id-bat-edi-body-part vaedim-body-part ATTRIBUTE WITH ATTRIBUTE-SYNTAX SequenceNumber -- sequence number of the forwarded EDIM entry. SINGLE VALUE ::= id-bat-edim-body-part vamessage-parameters ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageParameters SINGLE VALUE ::= id-bat-message-parameters vamessage-data ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageData SINGLE VALUE ::= id-bat-message-data -- Externally Defined Body Part Types vaexternally-defined-body-part-types ATTRIBUTE WITH ATTRIBUTE-SYNTAX OBJECT IDENTIFIER MATCHES FOR EQUALITY MULTI VALUE ::= id-bat-externally-defined-body-part-types -- Description of the externally-defined-body-part-types attribute syntax for parameter portion only tyEDIExternallyDefinedBodyPartParameterAttribute ::= SEQUENCE { body-part-reference [0] BodyPartReference OPTIONAL, parameter [1] ExternallyDefinedParameters } -- Notification Attributes -- Common Fields vasubject-edim ATTRIBUTE WITH ATTRIBUTE-SYNTAX SubjectEDIMField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-subject-edim vaedin-originator ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDINOriginatorField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-edin-originator vafirst-recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX FirstRecipientField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-first-recipient vanotification-time ATTRIBUTE WITH ATTRIBUTE-SYNTAX NotificationTimeField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-nat-notification-time vanotification-security-elements ATTRIBUTE WITH ATTRIBUTE-SYNTAX SecurityElementsField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-notification-security-elements vaedin-initiator ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDINInitiatorField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-edin-initiator vanotification-extensions ATTRIBUTE WITH ATTRIBUTE-SYNTAX NotificationExtensionsSubField MATCHES FOR EQUALITY MULTI VALUE ::= id-nat-notification-extensions -- Positive Notification Extension Fields vapn-supplementary-information ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDISupplementaryInformation MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-nat-pn-supplementary-info vapn-extensions ATTRIBUTE WITH ATTRIBUTE-SYNTAX PNExtensionsSubField MATCHES FOR EQUALITY MULTI VALUE ::= id-nat-pn-extensions -- Negative Notification Fields vann-reason ATTRIBUTE WITH ATTRIBUTE-SYNTAX NNReasonCodeField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-nn-reason-code vann-supplementary-information ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDISupplementaryInformation MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-nat-nn-supplementary-info vann-extensions ATTRIBUTE WITH ATTRIBUTE-SYNTAX NNExtensionsSubField MATCHES FOR EQUALITY MULTI VALUE ::= id-nat-nn-extensions -- Forwarded Fields vaforwarded-to ATTRIBUTE WITH ATTRIBUTE-SYNTAX ForwardedTo MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-forwarded-to vafn-reason-code ATTRIBUTE WITH ATTRIBUTE-SYNTAX FNReasonCodeField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-fn-reason-code vafn-supplementary-information ATTRIBUTE WITH ATTRIBUTE-SYNTAX EDISupplementaryInformation MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-nat-fn-supplementary-info vafn-extensions ATTRIBUTE WITH ATTRIBUTE-SYNTAX FNExtensionsSubField MATCHES FOR EQUALITY MULTI VALUE ::= id-nat-fn-extensions END -- of EDIMSMessageStoreAttributes ANNEX D Reference definition of Message Store Auto-Action Attributes (This annex forms an integral part of this Recommendation.) This annex, a supplement to Annex C, defines for reference purposes the MS attributes specific to EDIM Messaging Auto-Actions. It uses the ATTRIBUTE macro of Recommendation X.501. ---------- moEDIMSAutoActionTypes {joint-iso- ccitt mhs-motis(6) edims(7) modules(0) message-store-auto- actions(7)} DEFINITIONS ::= BEGIN -- Prologue -- Exports everything. IMPORTS -- EDIMS Object Identifiers id-act-edi-auto-forward ---- FROM EDIMSObjectIdentifiers {joint-iso-ccitt mhs-motis(6) edims(7) modules(0) object-identifiers(0)} -- EDIMS Information Objects EDISupplementaryInformation, RecipientField, ActionRequestField EDINotificationRequestsField, ResponsibilityPassingAllowed ---- FROM EDIMSInformationObjects {joint-iso-ccitt mhs-motis(6) edims(7) modules(0) information-objects(2) } -- MS Abstract Service AUTO-ACTION, Filter ---- FROM MSAbstractService {joint-iso-ccitt mhs-motis(6) ms(4) modules(0) abstract- service(1)} -- MS General Auto Actions PerMessageAutoForwardFields, PerRecipientAutoForwardFields ---- FROM MSGeneralAutoActionTypes {joint-iso-ccitt mhs-motis(6) ms(4) modules(0) general-auto-action-types(3) } -- MTS Upper Bounds ub-recipients ---- FROM MTSUpperBounds {joint-iso-ccitt mhs-motis(6) mts(3) modules(0) upper-bounds(3) } -- MTS Abstract Service Definition ORName ---- FROM MTSAbstractService {joint-iso-ccitt mhs-motis(6) mts(3) modules(0) mts- abstract-service(1) }; -- END Imports -- Auto-Action Types -- EDI Auto Forwarding Registration moedi-auto-forward AUTO-ACTION REGISTRATION PARAMETER IS EDIForwardRegistrationParameter ::= id-act-edi-auto-forward moEDIForwardRegistrationParameter ::= SEQUENCE { filter [0] Filter OPTIONAL, edi-supplementary-info [1] EDISupplementaryInfo OPTIONAL, delete-after-forwarding [2] BOOLEAN DEFAULT FALSE, edi-forwarding-mode CHOICE { forwarding-with-responsibility-not-accepted [3] ForwardWithRespForwarded, forwarding-with-responsibility-accepted [4] ForwardWithRespAccepted } Auto Action Registration Parameters for Forwarding with Responsibility not Accepted moForwardWithRespNotAccepted ::= SET { COMPONENTS OF PerMessageAutoForwardFields, -- from envelope PerMessageFields per-recipient-field [3] PerRecipientAutoForwardFields, notification-argument [4] NotificationArguments OPTIONAL } moNotificationArguments ::= SET { COMPONENTS OF PerMessageAutoForwardFields, -- from envelope PerMessageFields per-recipients-field [3] SEQUENCE SIZE (1..ub- recipients) OF PerRecipientAutoForwardFields } Auto Action Registration Parameters for Forwarding with Responsibility Accepted moForwardWithRespAccepted ::= SET { COMPONENTS OF PerMessageAutoForwardFields, -- from envelope PerMessageFields per-recipients-field [3] SEQUENCE SIZE (1..ub- recipients) OF PerRecipientAutoForwardFields, notification-argument [4] NotificationArguments OPTIONAL, heading-fields [5] HeadingFields OPTIONAL } moHeadingFields ::= SEQUENCE { new-edin-receiver-name [0] ORName OPTIONAL, next-recipient [1] RecipientField, next-recipient-action-request [2] ActionRequestField DEFAULT {id-for-action}, next-recipient-edi-notification-requests-field [3] EDINotificationRequestsField OPTIONAL, next-responsibility-passing-allowed [4] ResponsibilityPassingAllowedField DEFAULT FALSE } END -- of EDIMSAutoActionTypes ANNEX E Reference definition of EDIMS Functional Objects (This annex forms an integral part of this Recommendation.) This annex defines for reference purposes the functional objects of EDI Messaging. It uses the OBJECT and REFINE macros of Recommendation X.407. ---------- moEDIMSFunctionalObjects {joint- iso-ccitt mhs-motis(6) edims(7) modules(0) functional- objects(1)} DEFINITIONS IMPLICIT TAGS ::= BEGIN -- Prologue -- Exports everything. IMPORTS -- EDIMS Abstract Service origination, reception ---- FROM EDIMSAbstractService {joint-iso-ccitt mhs-motis(6) edims(7) modules(0) abstract-service(3)} -- EDIMS Object Identifiers id-ot-edime, id-ot-edims, id-ot-edi-ms, id-ot-edi-ua, id-ot-edimg-user, id-ot-pdau, id-ref-primary, id-ref-secondary ---- FROM EDIMSObjectIdentifiers {joint-iso-ccitt mhs-motis(6) edims(7) modules(0) object-identifiers(0)} -- MS Abstract Service retrieval ---- FROM MSAbstractService {joint-iso-ccitt mhs-motis(6) ms(4) modules(0) abstract- service(1)} -- MTS Abstract Service administration, delivery, mTS, submission ---- FROM MTSAbstractService {joint-iso-ccitt mhs-motis(6) mts(3) modules(0) mts- abstract-service(1)} -- Abstract service definition conventions OBJECT, REFINE ---- FROM AbstractServiceNotation {joint-iso-ccitt mhs-motis(6) asdc(2) modules(0) notation(1) }; -- END imports -- "Root" Object Type vaedime OBJECT ::= id-ot-edime Primary Refinement vaedime-refinement REFINE edime AS edims origination [S] PAIRED WITH edimg-user reception [S] PAIRED WITH edimg-user edimg-user RECURRING ::= id-ref-primary -- Primary Object Types -- EDI User vaedimg-user OBJECT PORTS { origination [C], reception [C] } ::= id-ot-edimg-user EDI Messaging System vaedims OBJECT PORTS { origination [S], reception [S] } ::= id-ot-edims -- Secondary Refinement vaedims-refinement REFINE edims AS mTS submission [S] PAIRED WITH edi-ua, edi-ms delivery [S] PAIRED WITH edi-ua, edi-ms administration [S] PAIRED WITH edi-ua, edi-ms edi-ua RECURRING origination [S] VISIBLE reception [S] VISIBLE edi-ms RECURRING submission [S] PAIRED WITH edi-ua retrieval [S] PAIRED WITH edi-ua administration [S] PAIRED WITH edi-ua pdau RECURRING reception [S] VISIBLE ::= id-ref-secondary -- Secondary Object Types -- EDI User Agent vaedi-ua OBJECT PORTS { origination [S], reception [S], submission [C], delivery [C], retrieval [C], administration [C] } ::= id-ot-edi-ua -- EDI Message Store vaedi-ms OBJECT PORTS { submission [S], retrieval [S], administration [S], submission [C], delivery [C], administration [C] } ::= id-ot-edi-ms -- Physical Delivery Access Unit vapdau OBJECT PORTS { reception [S] } ::= id-ot-pdau END -- of EDIMSFunctionalObjects ANNEX F Reference definition of EDIMS Abstract Service (This annex forms an integral part of this Recommendation.) This annex defines for reference purposes the EDIMS Abstract Service. It uses the PORT and ABSTRACT-OPERATION and ABSTRACT-ERROR macros of Recommendation X.407. ---------- moEDIMSAbstractService {joint-iso- ccitt mhs-motis(6) edims(7) modules(0) abstract-service(3)} DEFINITIONS IMPLICIT TAGS ::= BEGIN -- Prologue -- Exports everything. IMPORTS -- EDIMS Information Objects Heading, EDIM, EDIN, InformationObject ---- FROM EDIMSInformationObjects {joint-iso-ccitt mhs-motis(6) edims(7) modules(0) information-objects(2) } -- EDIMS Object Identifiers id-pt-origination, id-pt-reception ---- FROM EDIMSObjectIdentifiers {joint-iso-ccitt mhs-motis(6) edims(7) modules(0) object-identifiers(0) } -- MTS Abstract Service MessageDeliveryEnvelope, MessageSubmissionEnvelope, MessageSubmissionIdentifier, MessageSubmissionTime, ProbeSubmissionEnvelope, ProbeSubmissionIdentifier, ProbeSubmissionTime, RecipientImproperlySpecified, ReportDeliveryEnvelope ---- FROM MTSAbstractService {joint-iso-ccitt mhs-motis(6) mts(3) modules(0) mts- abstract-service(1) } -- Abstract service definition conventions ABSTRACT-ERROR, ABSTRACT-OPERATION, PORT ---- FROM AbstractServiceNotation {joint-iso-ccitt mhs-motis(6) asdc(2) modules(0) notation(1) }; -- Primary Port Types -- Origination vaorigination PORT CONSUMER INVOKES { OriginateProbe, OriginateEDIM, OriginateEDIN } ::= id-pt-origination -- Reception vareception PORT SUPPLIER INVOKES { ReceiveReport, ReceiveEDIM, ReceiveEDIN } ::= id-pt-reception -- ABSTRACT OPERATIONS -- Origination Abstract Operations -- Originate Probe tyOriginatePro ::= ABSTRACT- OPERATION ARGUMENT SET { envelope [0] ProbeSubmissionEnvelope, content [1] EDIM } RESULT SET { submission-identifier [0] ProbeSubmissionIdentifier, submission-time [1] ProbeSubmissionTime } ERRORS { RecipientImproperlySpecified } -- Originate EDIM tyOriginateEDIM ::= ABSTRACT-OPERATION ARGUMENT SET { envelope [0] MessageSubmissionEnvelope, content [1] EDIM } RESULT SET { submission-identifier [0] MessageSubmissionIdentifier, submission-time [1] MessageSubmissionTime } ERRORS { RecipientImproperlySpecified } -- Originate EDIN tyOriginateEDIN ::= ABSTRACT-OPERATION ARGUMENT SET { envelope [0] MessageSubmissionEnvelope, content [1] EDIN } RESULT SET { submission-identifier [0] MessageSubmissionIdentifier, submission-time [1] MessageSubmissionTime } ERRORS { RecipientImproperlySpecified } -- Reception Abstract Operations -- Receive Report tyReceiveReport ::= ABSTRACT-OPERATION ARGUMENT SET { envelope [0] ReportDeliveryEnvelope, undelivered-object [1] InformationObject OPTIONAL } RESULT ERRORS {} -- Receive EDIM tyReceiveEDIM ::= ABSTRACT-OPERATION ARGUMENT SET { envelope [0] MessageDeliveryEnvelope, content [1] EDIM } RESULT ERRORS {} -- Receive EDIN tyReceiveEDIN ::= ABSTRACT-OPERATION ARGUMENT SET { envelope [0] MessageDeliveryEnvelope, content [1] EDIN } RESULT ERRORS {} END -- of EDIMSAbstractService ANNEX G Reference definition of EDIMS Upper Bounds Parameters (This annex forms an integral part of this Recommendation.) This annex defines for reference purposes the upper bounds of various variable-length information items whose abstract syntaxes are defined in the ASN.1 modules of prior annexes. ---------- moEDIMSUpperBounds { joint-iso-ccitt mhs-motis(6) edims(7) modules(0) upper-bounds(5) } DEFINITIONS ::= BEGIN -- Prologue -- Exports everything. IMPORTS -- nothing -- ; -- Upper bounds ubub-application-reference INTEGER ::= 14 ubub-authorization-information INTEGER ::= 10 ubub-authorization-information-qualifier INTEGER ::= 2 ubub-communications-agreement-id INTEGER ::= 35 ubub-edi-association-assigned-code INTEGER ::= 6 ubub-edi-application-security-elements INTEGER ::= 8191 ubub-edi-controlling-agency INTEGER ::= 2 ubub-edi-document-release INTEGER ::= 3 ubub-edi-document-version INTEGER ::= 3 ubub-edi-message-type INTEGER ::= 6 ubub-identification-code-qualifier INTEGER ::= 4 : ::= 35 ubub-interchange-control-referenceub:ub-interchange- control-reference INTEGER ::= 14 ubub-local-referenceub:ub-local-reference INTEGER ::= 64 ubub-processing-priority-codeub:ub-processing-priority- code INTEGER ::= 1 ubub-reason-codeub:ub-reason-code INTEGER ::= 32767 ubub-recipient-reference-qualifierub:ub-recipient- reference-qualifier INTEGER ::= 2 ubub-recipient-referenceub:ub-recipient-reference INTEGER ::= 14 ubub-routing-addressub:ub-routing-address INTEGER ::= 14 ubub-syntax-identifierub:ub-syntax-identifier INTEGER ::= 4 ubub-syntax-versionub:ub-syntax-version INTEGER ::= 5 END -- of EDIMSUpperBounds ANNEX H Reference definition of Directory Object Classes and Attributes (This annex forms an integral part of this Recommendation.) This annex defines for reference purposes the object identifiers, object classes, attributes, and attribute syntaxes specific to EDI use of Directory. It uses the OBJECT-CLASS, ATTRIBUTE, and ATTRIBUTE-SYNTAX macros of Recommendation X.501. Annex J contains a discussion and description of the objects defined here. --------- moEDIUseOfDirectorymo:EDIUseOfDirectory {joint-iso-ccitt mhs-motis(6) edims(7) modules(0) edi-directory-cl- att(6) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- Prologue -- Exports everything IMPORTS -- EDIMS Object Identifiers id-dir ---- FROM EDIMSObjectIdentifiers {joint-iso-ccitt mhs-motis(6) edims(7) modules(0) object-identifiers(0) } -- EDIMS Information Objects EDIBodypartType, EDIMesssageTypeFieldSubField, SyntaxIdentifier, SyntaxVersion ---- FROM EDIMSAbstractService { joint-iso-ccitt mhs-motis(6) edims(7) modules(0) information-objects(2) } -- EDIMS Upper bounds ub-edi-association-assigned-code, ub-edi-controlling-agency, ub-edi-document-release, ub-edi-document-version ---- FROM EDIMSUpperBounds {joint-iso-ccitt mhs-motis(6) edims(7) modules(0) upper- bounds(5) } -- MHS Directory Object Classes and Attributes mhs-user, mhs-user-agent, mhs-message-store ---- FROM MHSDirectoryObjectAndAttributes {joint-iso-ccitt mhs-motis(6) arch(5) modules(0) directrory(1) } -- Information Framework ATTRIBUTE, ATTRIBUTE-SYNTAX, OBJECT-CLASS ---- FROM InformationFramework { joint-iso-ccitt ds(5) modules(1) informationFramework(1) } -- Selected Object Classes applicationEntity, top ---- FROM SelectedObjecClasses {joint-iso-ccitt ds(5) modules(1) selectedObjectClasses(6) } -- Selected Attribute Types and Syntaxes caseExactStringSyntax ---- FROM SelectedAttributeTypes {joint-iso-ccitt ds(5) modules(1) selectedAttributeTypes(5) }; -- END Imports -- OBJECT IDENTIFIER ASSIGNMENTS FOR USE OF DIRECTORY -- Categories idid-doc ID ::= {id-dir 0} -- directory object classes idid-dat ID ::= {id-dir 1} -- directory attribute types idid-das ID ::= {id-dir 2} -- directory attribute syntaxes -- Directory Object Classes idid-doc-edi-user ID ::= {id-doc 0} idid-doc-edi-user-agent ID ::= {id-doc 1} idid-doc-edi-message-store ID ::= {id-doc 2} -- Directory Attribute Types idid-dat-edi-name ID ::= {id-dat 0} idid-dat-edi-routing-address ID ::= {id-dat 1} idid-dat-edi-capabilities ID ::= {id-dat 2} -- Directory Attribute Syntaxes idid-das-edi-capabilities ID ::= {id-das 0} -- END Object Identifier Assignments -- Object Classes for EDI Use of Directory -- EDI User vaedi-user OBJECT CLASS SUBCLASS OF top MUST CONTAIN {edi-name} MAY CONTAIN {edi-routing-address, edi-capabilities} ::= id-doc-edi-user -- EDI User Agent vaedi-user-agent OBJECT-CLASS SUBCLASS OF mhs-user-agent MAY CONTAIN {edi-capabilities} ::= id-doc-edi-user-agent -- EDI Message Store vaedi-message-store OBJECT-CLASS SUBCLASS OF mhs-message-store MAY CONTAIN {edi-capabilities} ::= id-doc-edi-message-store -- ATTRIBUTES -- EDI Name vaedi-name ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseExactStringSyntax SINGLE VALUE ::= id-dat-edi-name -- The edi-name shall be one of the following: -- * a name assigned by an EDI naming authority, e.g. the Sender-ID or the Receiver-ID, -- * a name assigned by the EDI user's organization. -- EDI Routing Address vaedi-routing-address ATTRIBUTE WITH ATTRIBUTE-SYNTAX caseExactStringSyntax SINGLE VALUE ::= id-dat-edi-routing-address -- The term edi-routing-address reflects its derivation from a data element in the -- EDI Interchange with the same name. -- EDI Capabilities vaedi-capabilities ATTRIBUTE WITH ATTRIBUTE-SYNTAX edi-capabilities-syntax MULTI VALUE ::= id-dat-edi-capabilities -- ATTRIBUTE SYNTAXES -- EDI Capabilities Syntax vaedi-capabilities-syntax ATTRIBUTE-SYNTAX EDIUserCapability MATCHES FOR EQUALITY ::= id-das-edi-capabilities tyEDIUserCapability ::= SEQUENCE { edi-bodypart-type [0] EDIBodypartType OPTIONAL edi-processable-document [1] EDIProcessableDocument OPTIONAL } tyEDIProcessableDocument ::= SEQUENCE { standardVersion [0] SyntaxVersion OPTIONAL, standardSyntaxId [1] SyntaxIdentifier OPTIONAL, documentType [2] EDIMessageTypeFieldSubField OPTIONAL, documentVersion [3] DocumentVersion OPTIONAL, documentRelease [4] DocumentRelease OPTIONAL, controllingAgency [5] ControllingAgency OPTIONAL, associationAssignedCode [6] AssociationAssignedCode OPTIONAL } vaAssociationAssignedCode ::= T61String (SIZE(1..ub-edi-association-assigned-code)) vaControllingAgency ::= T61String (SIZE(1..ub-edi-controlling-agency)) (SIZE(1..u (SIZE(1..ub-edi-document-release)) vaDocumentVersionva:DocumentVersion ::= NumericString (SIZE(1..ub-edi-document-version)) END -- EDIMUseOfDirectory module ANNEX I Enhanced Security Model (This annex forms an integral part of this Recommendation.) I.1 Introduction This annex describes the enhancements required to the security model defined in Recommendation X.402. I.2 Security Services The additional security services and pervasive mechanisms described in Recommendation F.435 require the security model defined in 10 of Recommendation X.402 to be enhanced with the following security services: - Non-repudiation/Proof of Reception; - Non-repudiation/Proof of Retrieval; - Non-repudiation/Proof of Transfer; - Non-repudiation of Content. I.3 Enhancements to Clause 10.2: Security Services I.3.1 Changes to Recommendation X.402 Changes to Table 7 of Recommendation X.402 are shown in Table I.1. Two new classes of services are added; these are EDIM Responsibility Authentication and Non-repudiation of EDIM Responsibility. I.3.2 EDIM Responsibility authentication services I.3.2.1 Proof of EDI Notification This security service enables the originator of a message to obtain corroboration that his message has been received, and EDIM Responsibility has been accepted, forwarded, or refused. This service may be provided by using the Content Integrity check on message submission applied to the EDI Notification of the subject EDIM. I.3.2.2 Proof of retrieval This security service enables the MS administrator to obtain corroboration that a particular message has been retrieved from the EDI-MS by the EDI-UA. Implementation of this security service is a local issue. Additional pervasive mechanisms described in Recommendation F.435 may be used to provide this service. I.3.2.3 Proof of transfer This security service enables an MTA or an MD to obtain corroboration that a message has been transferred (relayed) to another MTA or MD. Implementation of this security service is a local issue. Additional pervasive mechanisms described in Recommendation F.435 may be used to provide this service. I.4 Non-repudiation of EDIM Responsibility services I.4.1 Non-repudiation of EDI Notification This security service provides the Originator of a message with irrevocable proof that the message has been received, and EDIM Responsibility has been accepted, forwarded, or refused. I.4.2 Non-repudiation of retrieval This security service provides the EDI-MS administrator and t e EDI- UA with irrevocable proof that a message has been retrieved from the EDI-MS by the EDI-UA. Implementation of this security service is a local issue. Additional pervasive mechanisms described in Recommendation F.435 may be used to provide this service. I.4.3 Non-repudiation of transfer This security service provides an MTA or an MD with irrevocable proof that a message has been transferred (relayed) to another MTA or MD. Implementation of this security service is a local issue. Additional pervasive mechanisms described in Recommendation F.435 may be used to provide this service. I.4.4 Non-repudiation of Content This security service provides an EDIMG user with irrevocable proof of the authenticity and integrity of the content of the message. This security service may be provided in two ways: (1) using a Notarisation Mechanism, or (2) using the Non-repudiation of Origin security service applied to the subject message and the EDI Notification of the subject message, provided the EDI Notification includes irrevocable proof of the content of the subject message.